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.

A friend of mine is introducing use cases to his company, and asked for some advice. It sounds like an interesting project — they’ll be using it for both a hardware and software component.

Here’s what I told him:

• Spend a lot of time talking about what’s actually going to be covered in the use cases up front, and try to stay flexible.
• When you’re working on the use cases, there’s a good chance that you’ll spend some time talking to people and eventually think, “I understand now, I don’t have to talk about this any more.” It’s useful to learn to recogize that feeling as an indicator that you need to verify everything one more time.
• Also, recognize that when you think, “This person doesn’t really understand this, but I’ll give them what I know they need” that roughly translates to, “There’s something here that I don’t understand, and I need to tease it out of the person.”
• Don’t be afraid to scrap everything and start over. It’s a lot cheaper to do that now than after you start coding.
• And don’t let anyone convince you not to do that one last review — that’s the one that will find the really BIG problem.