Managing The Quality Function

Product quality management is the executive function that owns the process for delivering products of the quality required by the marketplace. The function starts with good product requirements, moves to a development process that is designed to deliver predictable results based on the requirements, and ends with a quality control process (testing), which validates that the product indeed meets the defined requirements.

The development process must include explicit quality assurance steps to succeed. However, most company executives concentrate on requirements and other aspects of development, treating quality assurance activities as an afterthought.

Few organizations have a designated quality management function, although some have a software test department. Others have a quality assurance department that they refer to as "software QA," but it is really a software test group. Invariably, and despite protests to the contrary, this "software QA" department is often the weak link in the chain. Companies manifest the symptoms of this weakness in various ways:

■ The software quality assurance function itself is typically a "hot potato," which no senior manager wants to own. The function is moved around from engineering to manufacturing to operations and back to engineering. It seesaws between a centralized and decentralized function every couple of years.

■ Two companies that QualityLogic recently interviewed dissolved the central QA function, redeploying the engineers to the product teams and causing a great deal of disruption. Both organizations came to the conclusion that the central function was not working well after two to three years of effort to make it an effective business tool. In another case, the vice president who had been "given" QA was all too happy to hand it off to an outside company.

■ There is discontinuity in the management of the QA function itself. It is difficult to find and keep a good manager in software testing or software QA. Instead, managers often move out of the function. If they are really good, they are often hired away for more money; if they are ineffective, they are often fired. In any case, it is rare to find stable management of the software QA or test function.

■ There is no encouragement; it is rare that highly respected developers move to software QA. In fact, the opposite is true. Many companies are proud of the fact that they can use software QA as an entry point and training ground for development. The most attractive career path available to the QA engineer is to move to development.

■ For example, one of QualityLogic's major customers has a terrible time keeping good test leads. Hired right out of college, they have been screened for good development skills and are moved into development as soon as they become effective test leads. While this works well for the development organization, it continually leaves software QA with an inexperienced staff.

■ There is a constant turnover in QA staff. The consequence is that the QA organization never matures to the same level of skill and professionalism as development teams. Companies are often proud to have a stable QA organization for one or two years. This is in sharp contrast to the stability and maturity of the development team, which has typically been the same for five years or more. Thus, the company should recognize that the QA team is not even close to adequate for the task.

■ The use of developers as testers. A major QualityLogic customer recently needed help with a critical project. Its division management had just fired all of the QA engineers in an attempt to "fix" the quality problem. The company's ISO 9000 model stated that developers should actually do all of the quality assurance and final acceptance testing themselves — but this group just did not have the bandwidth to do so.

■ Although developers should indeed "own" the quality of their work, and should conduct such quality assurance activities as unit testing and peer reviews, they should not be the final product testers. Developers are seldom motivated or particularly competent as final product testers. In addition, the lost-opportunity cost of pulling them off of development work is staggering, when analyzed.

■ The development engineers successfully lay the blame for quality/schedule/feature problems on software QA. The weak link is a test or QA team that is unable to effectively advocate its own position; the team gets dumped on over and over again.

■ One major company is currently debating how to fix this very problem. The organization has an excellent QA team that does system test, but it works under the vice president of engineering. Because it is part of engineering, the QA team relieves the development teams from passing all the entry criteria before a product's acceptance for system test. Of course, QA is then blamed when the ship date slips.

■ While this situation is very typical, it is also easily solvable. The business manager must determine clear accountability for both development and QA functions, and establish a quality management function to enforce policy.

■ The QA team is unable to communicate product quality information to decision-makers — primarily the business manager. The team might lack the experience to decide when information is critical to the business manager.

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.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment