dick scherrer wrote:Hello,
One of the biggest "pitfalls" that cause production problems (abends/incorrect data) is insufficient testing.
When new code is developed it is critical to make sure that all of the code is tested. Simply running a test that does not abend is not sufficient. One way to more thoroughly test is to prepare what the expected output from a test should be and make sure that the actual output from the test matches the expected result.
If the code is to process "new" data (i.e. user input), every part of every field entered must be thoroughly validated. Often this is accomplished by creating a series of transactions that include both good and bad entries. The testing directions describe everything that should happen for both accepted and rejected entries. This includes data entered from a terminal or generated external to the application to be processed as input "transactions".
Not likely. Code to do this would need to even be "smarter" than the compiler. How would "bad data manipulation" be defined?However, it could be also possible to create routines that inspect the source code in order to detect bad data manipulations or error-prone statements because, sometimes people can miss some problems or can forget to test. No ?
Not on a well-managed project. People do not have the chance "to forget". The test plan is formalized detailing every business rule and the ways each will be tested.sometimes people can miss some problems or can forget to test.
Large, sophisticated testing is often automated. This handles both volume and testing consistency.(in fact, routines could automate what you do manually)