Assistance with constraint violation error messages

Post #112,575 by boxley 8/3/03 9:33:21 PM Reply	Assistance with constraint violation error messages Have a customer who is testing constraint violations. The customer insists that receiving an accurate constraint error message without a error code from the application is a sev 2 bug. example, violating date and time constraint. error: date/time field must be in the format of mmddyyyyhhmm 072920032359 they insist it should read application name, error number:date/time field must be in the format of mmddyyyyhhmm 072920032359 now I insist that unless the documentation calls for the latter format it is not a bug and testable as is. (meaning every instance of improper field entry should throw the same text message.) now I know it is nice to have app/error number but do not consider it a requirement unless documented as required. Any thoughts from the folks around here? Me I think they are using this as an excuse for being way behind their testing schedule. thanx, bill questions, help? [link\|mailto:pappas@catholic.org\|email pappas at catholic.org]
Post #112,577 by ChrisR 8/3/03 10:15:00 PM Reply	Depends how you define bug. As a software person, I define a bug in terms of my expectations of the software. If I designed the software to not output the error number or source of the error, that is not a bug. Since the software is acting correctly according to the software implementors intent, it's not what I consider to be a bug. The fault is either in the specification or the implementation of the features in the specification. The question is whether the specification stipulated the nature of the content for trap exceptions. The specs for presenting an error for human consumption can be quite different depending on the nature of the project. Some schemes just register a number. Others register a discourse on the exact nature of the exception - more than you ever wanted to know. Typically, end users are not necessarily cognizant of the names of the individual programs, modules, functions, etc... Giving them the information that lists the exact line number and function that registered the exception may be helpful for tracking things down from a software perspective, but that may not be useful information from the end users standpoint.
Post #112,578 by boxley 8/3/03 10:31:06 PM Reply	My thinking exactly Unless described in the documentation that an application error number should appear in that window it is working as designed. thanx, bill questions, help? [link\|mailto:pappas@catholic.org\|email pappas at catholic.org]
Post #112,579 by a6l6e6x 8/3/03 10:37:20 PM Reply	The question is what does the spec say? The discussion you are describing should have occurred while developing a spec. What is said in the spec specifically about that "error" or at least in general about interface errors? The idea is to test to an a spec agreed to prior to beginning the implementation. The spec is the contract between the developer and the user. If the spec says nothing, you've got one poor spec and never ending problems are resolved in a pissing contest. That's how you blow schedules and costs estimates. Otherwise, error numbers require that you look them up in a manual which may not be handy. Software interfaces use error numbers, not people. Alex If you don't know where you're going, any road will take you there.
Post #112,580 by JayMehaffey 8/3/03 11:32:39 PM Reply	Trivial bug I would consider that a minor bug at worst, and even then only if the application definition specified the error format or all the error messages except this one did follow some format. The only reason I can think of where this might be a real issue is if the testing involves using some error trapping tool that depends on the specific format of the error string. But even then I would be more inclined to consider it a bug in the testing tool then the program. Jay

Welcome to IWETHEY!