Many projects I have worked on in my career have suffered from misunderstandings about quality from the very beginning.  Software testers were told to “bang on” the software and do some “try to break it” tests (usually for some prescribed amount of time) and report back on what they found.  Sometimes,  work like that will find bugs — but there is always this nagging feeling that the testers might miss something important or that they might be looking at the wrong functionality entirely.  If you work on a project and find yourself worrying that the test team isn’t testing enough or is testing too much, the best way to address the problem is to focus your test on conformance to requirements.

By nailing down requirements early in the process and then testing to be sure they have been implemented correctly, the test team always stays on track.  The work that they do is, after all, being used to ensure that the product you release does what it was meant to do.  Effective test efforts are built around well-understood product requirements. In finding bugs, the test team is usually finding problems the product should address. Leaving the product quality up to some standard in your test team’s head will most likely lead to tests that are not focused on product functionality and that can mean that requirements of the software don’t get developed.  If the test team doesn’t understand the requirements from the beginning of the test effort, they have no way of knowing when those requirements aren’t met.

It’s commonly said  that testers and programmers don’t like each other.  I think that’s silly and wrong.  More often than not, the tester’s role is just left undefined.  Programmers, the story goes, feel antagonized by the tester’s criticism of their work and often dread having to deal with their test teams.  Focusing on software requirements, both in your development and your test effort can really help to alleviate some of this tension also.  Instead of seeing testers as annoying critics, programmers can see them as partners in implementing and validating the sofware project’s goals.  Good test plans and test cases can help to bring the programmers and testers together in their understanding of how this work will be done.  Allowing everyone to have a hand in understanding and approving of the requirements and the test strategy as a whole gives a test effort one focus and allows everyone on the team to feel a part of the work.