Alternatively, the team’
s information may be filtered through the current
owner, usually a vice president of development or engineering. As a result, the information serves the VP, but not the business manager.
§ Ship dates are frequently delayed, and the delays come as surprises (at first)—to everyone except the developers and testers. The testers did not try to make the information available to the business manager, or were unsuccessful in doing so.
§ Product design or features are routinely changed, causing schedule slips and expensive rework and retest, before release. Management accepts major design or feature changes because the basic process discipline was not controlled from a quality perspective. No one enforced the early steps of requirements verification or design review, and the impact on quality control activities was ignored in the decision process. This happens more often when there is an inadequate quality management function in place.
These problems all result because the business manager is not adequately investing in quality management. Nor is he or she willing to insist on accountability by the development group. In many cases, the definition of “adequate” is not understood, and quality management is undefended. Because quality in software is treated like an engineering function that no one really wants to own, it is no wonder that software QA people are also inadequately treated.
Thus, software test and QA engineering jobs are entry-level positions used as a training ground for development. Because the best people are routinely migrated to development, this perpetuates the weakness in quality organizations. An organization will have difficulty maturing when all of its members are entry level and intent on moving to development.
Furthermore, software test and QA engineers are treated as second-class citizens.
They are not considered as good as developers because of a bias that suggests:
“those not good enough to code, test,” or “those who can, write code; those who can’
t, test.”
In addition, software test and QA engineers are poorly paid relative to development engineers, and there is little or no career path for the former. Therefore, test and QA engineers do not have nearly the same opportunity as developers to rise in grade and pay.
This inequity extends to budget decisions, which also favor development over QA. If, for example, both QA and development ask for tool sets for their functions, and the company cannot afford both, development usually wins. Finally, management is willing to let QA suffer if development slips its schedule.
All of these problems and indicators stem from the business manager’
s lack of clear
understanding and valuing of software quality functions. This set of problems may be seen as cultural and management challenges facing the business manager.
SUCCESSFUL SOFTWARE QUALITY MANAGEMENT
Solving this proble m set is simple: business managers must clearly understand the quality requirements of their products, be willing to make appropriate strategic
decisions about them, and then put in place a quality management function. In the past, this has meant funding an independent software quality management group that does not report to engineering, and insists on disciplined behavior during the whole process. The group is typically used as a measurement and control mechanism.
Traditionally, an executive-level vice president, director, or manager of quality probably reported directly to the business manager. This provided adequate budget, experience, and power to enforce quality disciplines, and act as a gate for product release cycles. Currently, quality is often approached by integrating the quality functions into development teams via senior quality people, and establishing a clear, appropriate process for control of quality during development. While this can improve the organization’
s ability to develop high-quality products on time and within budget, it does not provide an objective, independent view of product quality to the business manager.
Alternatively, strong business managers can require that the quality function (usually just a test group) report to them directly. They can hire a vice president of quality to work directly for them, and manage the test function. They can ensure that the development vice president also views product quality management as important and sees the need for an independent quality function.
In the end, the business manager must spend a significant amount of effort and dollars to develop a strong QA organization. Three years ago, for example, one CEO
of a leading software company placed QA directly under him. Unfortunately, the QA manager was not strong enough, and a major release was shipped with significant problems. Only then did the CEO finally understand the caliber of manager required, and it took another few months to find that person. Now the company is in the rebuilding phase, and the jury is still out on the success of this approach. It is actually unusual that a business manager would make these decisions. Instead, most continue to struggle with this problem but never really solve it.
For business managers to succeed in the software business, both internal and external quality management functions require the following characteristics:
§ The business manager’
s clear definition and enforcement of a quality policy
§ Authority directly from the business manager, and independence, at least within the organization
§ Team stability and maturity as evidenced by pay, promotional opportunities, and team tenure comparable to development; an understanding of the business of developing successful software products; and earned respect from the whole organization
§ Ongoing investment in generic software testing and QA skills
§ Ongoing investment in tools and process improvement for the QA and test functions
§ An incentive structure that reinforces both effectiveness and efficiency in the QA and testing functions
If a company spends its resources in meeting these requirements, it can and will maintain a powerful quality assurance function equal to the other elements required for product success. However, these investments are often difficult for organizations
to justify, and they require sustained interest by the business manager. A viable alternative is to outsource some or all of software quality management, software quality assurance, or quality control to a third-party specialist in this area.
Outsourcing some or all aspects of the software quality management function is an emerging approach to the quality problem that has evolved naturally. This solution recognizes that the quality function must be done well, but it need not be a strategic internal competency. Quality management, quality assurance, and test comprise a discipline, complete with a generic methodology, process, and tools. Companies must determine whether it is a strategically good investment for them to outsource, or to develop and maintain this functional expertise themselves — which is an expensive proposition.
THE EVOLUTION OF SOFTWARE QUALITY MANAGEMENT
The business aspects of software quality are evolving, along with hardware platforms, software languages, software development tools, and the process of defining and building software products. There are at least five distinct models for organizing the software quality management function:
1. Developers do their own QA.
2. Test or QA engineers are integrated within the development teams .
3. A separate QA group belongs to the engineering manager or VP.
4. A separate QA group belongs to a VP other than the engineering VP.
5. A separate QA organization reports directly to the senior business manager (or a VP of quality who then reports to him or her).
The variety of specific solutions is not surprising, because the industry is still struggling to figure out this problem. Like the software business in general, each company seems intent on inventing its own model for software quality management.
Because all the models are based on a do-it-yourself approach, they are subject to the problems identified earlier. Outsourcing software QA activities is an emerging model that offers the business manager a viable option to solving product quality and quality ma nagement problems.
Historically, QA outsourcing consisted of low-cost, fast-turnaround supplements to internal testing efforts. Several outsourcing companies thrived by providing compatibility testing of software against various hardware platforms and comp onents.
Typically, client software companies would be running late on development and lack the in-house resources or equipment for fast-turnaround compatibility testing. So they turned to software QA outsourcing, contracting with independent test labs for specific test projects. And while this offered independence and objectivity, it aimed at solving a QA manager’
s staffing shortfall, rather than a business manager’
s basic
quality management problem.
This early model of outsourcing testing is rapidly evolving as major companies try to improve their quality processes. The use of outsourcing is not only accelerating, but
changing, as is illustrated by an outsourcing relationship with a leading PC
manufacturer.
In 1995, the PC manufacturer started systematically investigating testing laboratories, which it then used on small, noncritical projects that were not adequately staffed internally. There were reviews after each early project that tested localized software versions. The reviews identified how to improve the testing and communications processes on the next project. Thus, over time, the manufacturer developed trained, trusted people available to the its test organization for overflow work. The organization also planned to outsource some portion of the work and develop a set of trusted, long-term vendors.