Generally, testing is viewed as a the Quality Assurance person’s job, but that doesn’t quite capture the essence of the relationship. While QA’s primary tool is the test, the tests are the means to the end, rather than an end themselves.
If we look at any development process, developers always run their own code. They always check to see that it is working. Having a second set of eyes on it is important, but simply as part of being asked to solve a problem, they check to see that the problem is solved. This has been formalized, but it is important to recognize that the very definition of undertaking a task dictates a mechanism to determine that you have completed the task: a measure, or a Test.
This fundamental interpretation of taking action, indicates that “Testing” is part of developer’s responsibility. If we have assumed that Testing is the Quality Assurance Department’s responsibility and we have found that it is also the Development Department’s responsibility, we need to ask who else is responsible that we haven’t considered.
The answer is simple: everyone is a Tester, everyone is responsible for Testing.
Everyone has their area of expertise, and their area of expertise will create bias. This combination of bias and expertise means that some individuals are better at finding certain problems than others. We need to harness this range of expertise to maximize quality, while at the same time compensating for one another’s biases. This “Peer Review” process is what keeps us from falling into biased patterns.
Every stage of the development process is responsible to ensure the system is working as expected, and it is everyone’s responsibility to check one another’s work. Well documented tests allow us to verify and validate one another’s results, watching for mistakes that hide in our blind spots.
