|
||
"Committed to Excellence in Software Testing"
QualityAssurance & Testing; Rodger Drabick Whenever I enter a new organization, and someone starts talking about “Quality Assurance” or “Software Quality Assurance”, I always have to ask, “What do you mean by that_” To many developers and managers, the term “Quality Assurance” is synonymous with “Testing”. Years ago, I would have agreed with that statement. Today, I do not. I believe that “Quality Assurance” and “Testing” refer to two significantly different processes and functions, and I will make use of some of my “process diagrams” to illustrate my point. I will also justify this position by noting that since 1992, I have been working in projects, both at Eastman Kodak and at Amtrak, in which the two functions are separate. A detailed model of the formal testing process has been published in several Issues of the Software QA Magazine, beginning with Vol 2 Number 2 and concluding with Vol 4 Number 5. Figure 1 shows a top-level Input-Process-Output diagram, as suggested by Watts Humphrey, which I have used to model the Formal Testing Process.
The interested reader will note that this model identifies a standards-based life cycle testing process, that concentrates on developing formal test documentation (e.g., test plans, test design, test cases, test procedures) to implement repeatable structured testing on a software or hardware/software system. Though not shown at this top-level, the general intent is that the test documentation be developed based on a formal requirements specification document. The test plan identified within this model is intended to provide verification and validation of the requirements. Once the documentation is developed, the test is executed. The more detailed process diagrams underlying this top-level diagram show the details as to how the test documentation is reviewed, test execution is performed based on the documentation, pre and post test meetings are held, and a formal test report is generated that documents the successes and failures encountered during the test program. The Process Model for Formal Testing has five significant subprocesses:
I have also developed a similar process model for Quality Assurance. This process model is shown in Figure 2.
The Quality Assurance program for a project is founded on development of a Quality Assurance Plan early in the project life cycle. Like testing, Quality Assurance is a life cycle process. At this point, it becomes evident that in my process model for Quality Assurance, QA becomes quite different from testing. Following development of the QA Plan, the QA program involves the following activities (at the high level):
This process model for Quality Assurance, which is based on the QA functions identified in IEEE-Standard-730, shows QA as an organization intended to provide management with the proper information to properly run a development program. Note that this intent is quite similar to that identified in the way the Software Engineering Institute at Carnegie Mellon University identifies the Level 2 Key Process Area within its Capability Maturity Model for SQA. There is little of the outmoded concept of QA as the “policeman” in this model; the “police” htmlect of QA is contained within the “Perform Audits” subprocess. To me, the most significant function for QA is to Facilitate Process Improvement. The metrics data (some of that obtained as a result of the reviews) collected, and the risks identified and managed, can all assist in Process Improvement. Another advantage of Quality Assurance as proposed in this process model is the role of QA as a “test engineering monitor”. No longer does management and the development staff have to wonder “who is watching the testers”. With a separate QA organization, there is an agency available to provide objective review of testing activities. QA can assure that Test Engineering is following their defined process (as reflected in the Test Plan and other Test Documentation), and can assist Test Engineering in improving their process. From another perspective, what we see here by comparing the process models is how Test Engineering and Quality Assurance can work together to support a development project by providing a formal Quality Support Infrastructure. With the support of a Configuration Management organization, such an infrastructure provides effective support to management and development in bringing high-quality programs in on-time and within budget. In summary, then, I suggest to you that Test Engineering and Quality Assurance are two distinct disciplines, both of which are committed to improving the quality of delivered products. An effective organization will staff the separate organizations, and will provide the training and resources that will enable them to efficiently support the project. ============================================================================== AUTHOR PROFILE Rodger Drabick is a nationally recognized expert in software process engineering, software quality assurance and testing management with over 35 years experience. Rodger can be reached on xkejaguar@aol.com ============================================================================== |
||
