>>>> Every module is indepently tested and proven to work as designed. Most
>>>> of the problems I run into are related to bad data.
>>>
>>>you mean, as in, the module did not defend against (check for) bad data ?
>>>is data validation specified as part of your module specifications ?
>>>or do you just rely on field validation at input time ?
>>
>>In general yes. IMV, the module shouldn't have to check against invalid data. The reason for this is simple: functional cohesion. Adding validation at this point would result in the module being less cohesive. Therefore, validation should be the work of some other module.
>>
>>Note, that in some instances, it's entirely impossible to check for valid data. Example: A user is entering production. They enter 123. It's perfectly possible for this value to be valid and it's also possible that it could be invalid (did they mean to type 213? 312? etc.)
>
>George;
>
>How do we protect the data as well as ourselves from users? January of this year I had a user place character data into a SQL Server 7.0 date/time field. He did this several times and we could not duplicate it. Whenever the form was instantiated it would error out (ASP) and freeze the form at that data block. We looked at everything possible and even Microsoft had no answer to this. Data is validated on the form for type, etc. at the object level. That is each data entry object has code to validate data type and gives the user a message if an incorrect data type or format is entered. This should not have occurred but it did. I saved the record to prove it.
>
>I have some users that are “interesting”. Perhaps that is to be expected from the automotive industry. Sometimes I wish they were our SQA department! :)
>
Tom,

I know what you mean. I've always said that being developer/beta tester is an out and out bad combination. As the developer, I instinctively know what to do and what not to do. Keeping that out of even my subconscience, is an impossible task.