Every product manager and business owner must be certain of the quality of a release before it goes out. The only way to do this is to make sure you do a large amount of testing yourself, particularly on areas that you know are prone to misinterpretation. Any product or business person who says “I don’t do tests” is just not doing their job.
The optimal way for doing requirements is to create tables of “examples” that represent single-line, atomic definitions of what ‘tests’ should pass for a feature to work. This BDD approach leads to massive increase in shared understanding. It also leads itself immediately to automated testing, using tools like Cucumber.
Any organisation that implements a unit testing strategy but does not implement an automated acceptance test strategy only knows half of what can go wrong. They are building the thing right, but they do not know if they are building the right thing. Want to avoid a situation where no-one really knows what the software does? Write examples as acceptance tests and automate them.
- Automated Aceeptance Testing Strategy
- BDD and Specification by Example
- Creating atomic requirements for automation