"Is QA better at writing product specifications?" This thought passed through my head while reading a post a while back written by QA Girl. I asked this question to myself because in the past I was part of a group where QA successfully helped to write the product specifications. With past experiences under my belt my first thought was "Yes, QA is better at writing specifications", but after thinking a bit more about it I came to the conclusion of "not necessarily". To explain, I'll revisit how our QA group ended up writing specifications.

In the beginning... documents didn't contain the things that testers needed to write test cases and test. Mostly specifics, things like a textbox's allowed characters, min lengths, max lengths, defaults, or a button's behavior when clicked. Important specifics when it came to Web page design, functionality and security. Through the course of several projects the lack of specifics were expressed through defects, and those defects would be duplicated from one project to the next. Consistently. Consistent because the test cases were detailed and consistently shared across all projects. Verbal frustrations started flowing..."This document sucks, what am I testing here?", and then a new tag-line was born "Specification definition through defect input". Developers were adding to and rewriting specifications like crazy just so they could get their head around what was supposed to be developed (far too late in the process too!) Then, one fine day, in a company that was slowly moving to a more agile environment, QA's voice was heard and the marketing and design teams started asking "what do you want to see in the specification documents"?

Finally, the clouds were gloriously parted and a direct beam of sunlight was shining blissfully on QA's face. "What do we want? We want you to provide the product details that we have built into our test cases!" "You have the details in your test cases?" they asked with astonishment. "Yes, we defined them through defect input over the course of several projects." the QA team replied with pride. "Wow, can we get a copy of those cases?" was the sheepish response. But delivering that copy of test cases didn't fix the problem entirely. The next release and next document contained the first attempt at delivering those needs but somehow was still lacking the details. It seemed to QA that the design team couldn't translate QA talk/test cases. This was scary, since the test case were well designed, clear and concise. What was the hang-up? Did they not understand QA talk? The answer was not that but instead: lack of time. The design team had enough trouble keeping up with other details in the specification document, adding the new details (the right way) didn't fit into their design schedule. Ouch...But, how can you develop a product that is not designed?

What came next is what led to my first impression of "Is QA better at writing specifications" as being a big fat "Yes". The design team said "Can QA add those details to the specification document?" It is that we did, and by doing so, QA moved themselves earlier into the project (design phase) and ultimately satisfied the specification need.

Could the design team have done the same? Yes. Did they have time to do so? No. Thus, "Is QA better at writing product specifications?" Not necessarily. BUT...QA contribution is required during the design process. If the QA team can't help add details to the specification document during design then they must at least provide and translate those needs to the design team. In my experience, translation can be tough, something is always lost along the way, and it seems to be easier to cut out the middleman. With that said.... "Is QA better at writing product specifications?" Yes, for the purpose of testing needs.

To recap: "Is QA better at writing product specifications?" Yes. Not necessarily. Yes. Got it? Maybe it's better said: "Should QA contribute to the product specification?" and to that we say a big, fat, gihugey "YES".

Now, one's inner QA mind should be screaming "Danger! Danger! You can't do both, write the requirements and test them!" Ah, yes. You are right, you, a solo Test Engineer should not, but a Test team can. One QA individual can write them, another can test them, mitigating the risk while also giving the tester what he/she needs.

Now let's throw away my example and past experience and weigh a few pros and cons. I'm sure you can come up with more but when you add them and reweigh I'll bet your conclusion is the same as mine:

The Pros of QA contributing to specifications

• Specifications are written early, forcing QA to be involved early.
• Specifications will contain exactly what the Test Engineer needs during the Test phase.
• QA teams that are required to test documents aren't getting them in a waterfall fashion. You now have agile documentation testing going on!
• The QA team will be more knowledgeable of the product. Better knowledge of the product will result in better tests, better test estimates, and earlier definition and delivery of QA requirements (e.g. environments).Defects (design, functional, and detail) can be found before the product is developed saving costly redesign time later down the road.
• Fewer defects are found during the Testing Phase, giving the tester more time to focus on finding the harder, better hidden defects.
• The QA and Tester mind-set forces Design teams to think outside of the box.
• Fewer specification document updates occur in later project phases.

The Cons of QA contributing to specifications

• The specification writer can't test too. Testing needs fresh and unbiased eyes. If the tester writes the requirements they are biased when testing them.
• Lack of QA resources. You can't afford to take a resource from running test cases on another project(I'm really reaching here, see below)

By my calculations the pros outweigh the cons! If we mitigate the cons, QA contribution to specifications is a no-brainer. Let's mitigate those cons:/p>

• The QA/specification writer can't test too.
  • Mitigation: A minimum of two man test teams.
• Lack of QA resources
  • Mitigation: This is NOT a real problem! If your waterfall process has tricked you into thinking this is a problem then you can't afford not to! I promise you, you will see the savings in subsequent project phases by finding defects early vs. late. Worst case; imagine that you are taking a Developer's time from testing phase and putting that into the design phase for the Test Engineer. You break even, just less head-ache and stress at the end of the project. This con has now been converted to a pro!

Makes sense doesn't it? So....what are you going to do now? In case you missed the point, let's put this in a pretty TO DO list for you

• Include QA where needed in the requirements gathering process.
• Include QA in the specifications writing process.
• Budget less Developer resources in the testing phase and budget a QA resource to the requirements gathering/writing phase.
• Find issues early, before development begins, and avoid costly redesign.
• Smile with satisfaction because you have a less hectic and higher quality project.