Quality Assurance: Much More than Testing

By: STUART FELDMAN

ORGANIZATIONAL IMPLICATIONS AND APPROACHES
Since QA is a process, it is natural to expect special roles and organizations to be assigned to it. In simple and undemanding projects, the designers and developers may also perform QA tasks, just as they do in traditional debugging and unit testing. Unfortunately, people are usually loath to spend a lot of time on assurance tasks; developing new features is much more exciting. Furthermore, the people who miss a special case during design will also be likely to miss it during testing.

Therefore, in larger organizations or for products with stringent requirements, QA is usually the responsibility of a separate group. Ideally, that group is independent of the development organization and has authority to require redevelopment and retesting when needed. The independent QA people are typically responsible for defining the process and monitoring the details of execution. Sadly, QA people rarely remain best friends with developers.

A separate organization is capable of the deep analysis that supports improvement of the process and the product. High levels of SEI CMM (Software Engineering Institute Capability Maturity Model) certification and ISO quality certification require significant levels of analysis and feedback; the QA organization is the natural home for those activities.

A QA organization need not be huge to be effective. Relatively small groups can do a good job, so long as they have independence, knowledge of the process, and understanding of the product. The QA staff also needs to be experienced in the many ways that products can be botched, processes can be short-circuited, and people can be careless. Assigning QA tasks to the most junior member of the team dooms the product and the staff.

ACTIVITIES
Numerous textbooks and standards documents define the stages of QA. If you are going to be responsible for assuring quality, read them.
QA touches all stages of a software project. It typically requires careful capture and control of many artifacts, as well as strict version management. It is impossible to have a solid and replicable test plan without agreed-upon requirements and specifications.

In a traditional development process, the QA organization requires reviews at each stage, with careful records, verification, and signatures. Tests and release criteria are based on requirements, and release is based on test results. If there are product requirements for reliability and availability, you will need special testing environments and adequate amounts of time to acquire data.

In an agile programming environment, where requirements may be updated every few weeks as customers examine drafts of the software, the QA process needs to be more flexible than in a traditional environment. Nonetheless, someone must be responsible for assuring testing of basic requirements, rapidly updating and recording regression tests, and ensuring progress reviews. (Extreme programming does not excuse curdled databases.)

IS SOFTWARE REALLY HARDER THAN HARDWARE?
People are accustomed to software having more bugs than hardware. There are many reasons for this:
* The difficult, irregular, human-oriented parts of a system are left to the software.
* Conversely, the hardware usually has replicated components and considerable regularity, so the logical complexity may be much lower than the size of the design suggests. On the other hand, analog and mechanical issues can introduce new dimensions to the problem.
* Despite decades of experience, managers often plan the software after the hardware designs and tests have been completed. There is then neither time nor budget to support appropriate QA of the software.
* Hardware engineers have a deeply ingrained respect for quality, both through their education and because they know how hard it is to change a badly designed physical object.
Software engineers can learn a lot from their hardware colleagues about rigorous planning, process, and testing. Hardware people, on the other hand, can learn a lot about usability, flexibility, and complexity.

MAXIMIZE THE REWARD
The details of the QA process depend on the organization, staff, and expected use of the product. It can be difficult, tedious, odious, time-consuming, and expensive.

But it is also necessary. Learn to do QA well to minimize the pain and maximize the reward.

Full article...

Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/