what do they do?
1. They Are Sleuths . Perhaps most important, a QA person needs to be an investigator in order to define the job and understand the project. There may or may not be a product specification (spec) available defining the project. Too often the spec is nonexistent, bare bones, or woefully out of date. Furthermore, the difference between the original bare-bones spec and the current but undocumented reality is known and discussed only in private development meetings at which QA people are usually not present. QA is usually not deliberately excluded, just overlooked because development's focus is to accomplish the task, not necessarily to share their information with everyone.
Thus a QA person needs to have the investigative skills to seek out information through all available means: manuals, specs, interviews, emails, and good old trial and error. What is the product really supposed to do? What is the customer expectation? How will management know when the product is ready to ship? What measurable standards must be met? What are the individual developers working on now and what are they most concerned about? This investigation is the job of all QA people. Some experienced developers may find this in conflict with their experience, as some organizations set development tasks in a hierarchical way, with job specifications coming down from the architect and individual contributors dealing with specific focused subsets. It may seem natural to expect QA to work the same way, but in fact each QA person needs to be an independent investigator with a broad picture. Where developers are making code conform to specifications, QA people are looking for the needle-in-a-haystack problems and unexpected scenarios, in addition to verifying that the product actually works as expected.
2. They Know How to Plan . A QA person needs to plan and set priorities. There is a definable project to test. Given all the possible combinations of expected uses, as well as all the potential unexpected scenarios including human and mechanical failure, one can imagine an infinite number of possibilities. Organizing one's activity to get the most effective results in the (usually) limited time available is of paramount importance.
Further, this is an ever-changing evaluation. In ideal circumstances, QA is on pace with or even ahead of development. QA should be included in the earliest planning so that at the same time developers are figuring out how to build the code, QA is figuring out how to test the code, anticipating resource needs and planning training. But more likely, QA is brought to the project late in its development and is racing to catch up. This requires planning and prioritization with a vengeance.
Consider also that each new build represents a threat to established code. Code that worked in previous builds can suddenly fail because of coding errors, new conflicts, miscommunication, and even compiler errors introduced in the latest build. Therefore, each new build needs to be verified again to assure that good code remains good. A useful prioritization of tasks would be to
- spot-check the new build for overall integrity before accepting it for general testing
- verify that new bug fixes have indeed been fixed
- exercise new code that was just added, as this is the area most likely to have problems
- revalidate the established code in general as much as you can before the next build is released
Outside of straightforward functional testing, there may be requirements for performance testing, platform testing, and compatibility testing that should run in environments separate from the standard development and test environment. That's a lot of testing to manage. QA people