Mistake Proofing
Sometimes, we find that we’ve been doing something for so long, that the way that we do it becomes taken as as a given. Such is the relationship between software developers and QA testers. It has unfortunately become standard practice for the developers to write the code and the testers to find the bugs. This is a common although inefficient method of quality assurance in which defects are allowed to enter the system and then testing is used to try to discover them and have them removed. A far more efficient and effective method is to borrow from the concept of “mistake proofing” from lean manufacturing systems. The idea behind Mistake Proofing is to take steps to help ensure that defects never enter the system in the first place. This leads to higher quality of course but also to lower testing times, lower testing resources, and less re-work.
In the waterfall world with its functional silos, it is natural for development and QA to have a somewhat adversarial relationship at times. This is part of the nature of big hand-offs across functional boundaries. But as we all know, on Agile teams, testers are first-class members of the team who should be working very closely with developers, analysts, etc. But what exactly is the nature of that work? How exactly do developers and testers work closely together? I feel that one of the primary goals should be mistake-proofing. Mistake-proofing on a software development project involves:
a) Having developers and testers and analysts discuss feature requirements in great detail so that they all develop a common understanding of the requirements.
b) Discussing in some detail how exactly we are going to test each feature. Here is where the tester can add great value to the development process and help in the mistake-proofing process. The tester tells/discusses with the developer:
- The test scenarios that will be used
- The test data that will be used
- The boundary conditions that exist and what should happen in those cases
- Any use-cases or other work-flow paths that will be taken in order to get to the test-case at hand.
- What the system should do in the event of an error condition
- Test automation needs
- etc
In discussing the requirements and testing at this level of detail, we begin to treat test cases as first class requirements that the developer must take into account. By knowing exactly how the code will be tested, the developer can write code to pass the tests and thereby keep defects from ever entering the system. This is like getting the questions to the final exam before the final exam; you ought to be able to pass a test if you know the questions in advance.
The Role of QA
In this model, the QA role transforms from finding defects to:
- Specifying how to keep defects out of the system.
- Providing independent verification that the system works per the requirements
The result; fewer functional defects. And fewer functional defects means less time and resources spent finding them, tracking them, fixing them, and re-testing them. QA should then be able to focus more of their time on other higher value testing such as integration testing, end-to-end testing, etc., which are often short-changed in the pursuit of functional defects.
