Getting Testing Involved
There is a common anti-pattern I consistently run into involving testing. In this anti-pattern testing is about finding technical defects near the end of a project. Testers view their job as preventing a buggy product from being shipped to the customer. To accomplish this, testers define test cases from the requirements documents. Since requirements are going to change during the project, the testers need to wait until near the end of the project to produce their tests.
What’s wrong with this?
This model doesn’t work. The requirements documents don’t tell a perfect story in the first place. And the documents never stay in perfect alignment. Sometimes the tester interprets the requirement differently than the developer. Inevitably, development delivers something that doesn’t match what testers expect and they file a defect. To avoid defects, the developers have to anticipate everything that might be meant by the requirements. A result is that developers significantly overbuild or over-engineer the product. The bigger and more “dynamic” the product is, the bigger the testing effort.
A result of the anti-pattern is that the cost of producing working, tested software is significantly increased. We are less predictable...read more