Thus, the policy should carry the weight of the business manager, reflecting serious consideration and commitment. It should have lasting value, and be unambiguous to those implementing policy.
There really is value in thinking about and articulating such a policy. Quality problems in the software industry are caused by the lack of clear direction from the business manager and the will to enforce such policy.
Business managers can only hold their teams accountable for meeting quality standards if these are stated. A decision to ship a product can only be made when there are clear criteria for making such a decision. A development team can only be disciplined for causing exorbitant support headaches when team members are told that minimizing support costs is a critical issue at the time of software design. A product manager can only set quality goals for a product when the standard corporate policy is consistent from day to day and product to product.
The right policy must be set and articulated before it can be enforced. A business manager who does not step up to this issue is negligent in leading his organization.
MONITORING AND ENFORCING QUALITY POLICY
Once a quality policy is put in place, the second major issue is monitoring product quality to ensure that the policy is carried out. This means that business managers must establish a good quality management function that provides their organizations with good information about the quality of the products under development, and enforces their quality policies. The policies and their enforcement have failed if the business manager only finds out that customers are dissatisfied after a product has shipped.
The proactive business manager must determine if the products in development will be delivered on time, on budget, and with the quality required to succeed in the market. Uncommon managers, who have put in place the right organization and people with the right direction, need merely ask for the information, and it will be available in some form, providing an accurate view of the quality of products in development.
Unfortunately, for most organizations and business managers, this is an unrealized dream. While there may be a test team in place to measure product quality, it is probably buried in the development organization, wherein inexperienced staff report to an inexperienced test manager. Here, the right information seldom reaches the right people in time. Rather than an independent function, quality management is a lower-level quality control function, performed by the test team, which has minimal understanding of corporate quality policy and issues.
What the organization needs is a quality management team that:
§ Is independent of the development team
§ Is empowered with the authority of the business manager
§ Is working with the product on a day-to-day basis
§ Has the skills to thoroughly evaluate the product against explicit or implicit criteria, and can ferret out the evaluation criteria[3] from whatever internal sources are available — or raise a flag if adequate product requirements do not exist
§ Can professionally[4] provide documented information to both the development team and the business manager
§ Clearly understands the manager’
s business problem and is helping to solve
this above all else
§ Operates very efficiently and effectively
Unfortunately, it is difficult — if not impossible — for a business organization to put this definition in place internally.
[3 ]Most organizations call these criteria “requirements.” These are the specifications that the organization believes a product must meet in order to satisfy a customer need.
[4 ]Professionally means that the team provides information in a form, at a time, and in a way that is perceived as non-threatening, objective, and valuable. There is no appearance of a hidden bias or agenda. In short, the test team is respected and listened to by all parties. This is not usually the case with test teams.
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.