Monday, November 23, 2009

Barriers to Quality

People say they want quality; however, their actions may not support this view for the following
reasons:

  1. Many think that defect-free products and services are not practical or economical, and thus believe some level of defects is normal and acceptable. (This is called acceptable quality level, or AQL.)

  1. Quality is frequently associated with cost, meaning that high quality is synonymous with high cost. (This is confusion between quality of design and quality of conformance.) Organizations may be reluctant to spend on quality assurance, as they do not see an immediate payback.

  1. Quality by definition calls for requirements/specifications in enough detail so that the products produced can be quantitatively measured against those specifications. Few organizations are willing to expend the effort to produce requirements/specifications at the level of detail required for quantitative measurement.

  1. Many technical personnel believe that standards inhibit their creativity, and thus do not strive for compliance to standards. However, for quality to happen there must be well defined standards and procedures that are followed.

The contributors to poor quality in many organizations can be categorized as either lack of involvement by management (Phillip Crosby), or lack of knowledge about quality. Following are some of the specific contributors for these two categories:

Lack of involvement by management based on studies from Phillip Crosby
  • Management's unwillingness to accept full responsibility for all defects
  • Failure to determine the cost associated with defects (i.e., poor quality)
  • Failure to initiate a program to "manage defects"
  • Lack of emphasis on processes and measurement
  • Failure to enforce standards
  • Failure to reward people for following processes


Lack of knowledge about quality

  • Lack of a quality vocabulary, which makes it difficult to communicate quality problems and objectives
  • Lack of knowledge of the principles of quality (i.e., what is necessary to make it
  • happen)
  • No categorization scheme for defects (i.e., naming of defects by type)
  • No information on the occurrence of defects by type, by frequency, and by
  • location
  • Unknown defect expectation rates for new products
  • Defect-prone processes unknown or unidentified
  • Defect-prone products unknown or unidentified
  • An economical means for identifying defects unknown
  • Proven quality solutions are unknown and unused

If achieving quality (i.e., defect-free products and services) were easy, it would have been
accomplished years ago. Quality is very difficult to accomplish – it requires the close cooperation of management and staff. Achieving quality requires a commitment and the establishment of an environment in which quality can flourish.

Sunday, November 22, 2009

The Different Views of Quality

Industry accepted definitions of quality are “conformance to requirements” (from Philip Crosby) and “fit for use” (from Dr. Joseph Juran and Dr. W. Edwards Deming). These two definitions are not inconsistent.

Meeting requirements is a producer’s view of quality. This is the view of the organization responsible for the project and processes, and the products and services acquired, developed, and maintained by those processes. Meeting requirements means that the person building the product does so in accordance with the requirements. Requirements can be very complete or they can be simple, but they must be defined in a measurable format, so it can be determined whether they have been met. The producer’s view of quality has these four characteristics:
  • Doing the right thing
  • Doing it the right way
  • Doing it right the first time
  • Doing it on time without exceeding cost

Being fit for use is the customer’s definition. The customer is the end user of the products or services. Fit for use means that the product or service meets the customer’s needs regardless of the product requirements. Of the two definitions of quality, fit for use, is the more important. The customer’s view of quality has these characteristics:
  • Receiving the right product for their use
  • Being satisfied that their needs have been met
  • Meeting their expectations
  • Being treated with integrity, courtesy and respect

In addition to the producer and customer views of quality, the organizational infrastructure also includes a provider and a supplier view.

These views are as follows:
  • Provider view – This is the perspective of the organization that delivers the products and services to the customer.
  • Supplier view – This is the perspective of the organization (that may be external to the producer’s company, such as an independent vendor) that provides either the producer and/or the provider with products and services needed to meet the requirements of the customer.

The Two Quality Gaps
Most Information Technology (IT) groups have two quality gaps: the producer gap and the customer gap as shown in the figure below. The producer gap is the difference between what is specified (the documented requirements and internal standards) versus what is delivered (what is actually built). The customer gap is the difference between what the producers actually delivered versus what the customer wanted.


Closing these two gaps is the responsibility of the quality function. The quality function must first improve the processes to the point where the producer can develop the products according to requirements received and its own internal standards. Closing the producer's gap enables the IT function to provide its customers consistency in what it can produce. This has been referred to as the "McDonald's effect" - at any McDonald's in the world, a Big Mac should taste the same. It doesn't mean that every customer likes the Big Mac or that it meets everyone's needs, but rather, that McDonald's has now produced consistency in its delivered product.


Closing the second gap requires the quality function to understand the true needs of the customer. This can be done by customer surveys, Joint Application Development (JAD) sessions, and more user involvement through the process of building information products. The processes can then be changed to close the customer gap, keeping consistency while producing products and services needed by the customer.


Friday, November 20, 2009

Quality Control and Quality Assurance

Very few individuals can differentiate between quality control and quality assurance. Most quality assurance groups, in fact, practice quality control. This section differentiates between the two, and describes how to recognize a control practice from an assurance practice.

Quality means meeting requirements and meeting customer needs, which means a defect-free product from both the producer’s and the customer’s viewpoint. Both quality control and quality assurance are used to make quality happen. Of the two, quality assurance is the more important.

Quality is an attribute of a product. A product is something produced, such as a requirement document, test data, source code, load module or terminal screen. Another type of product is a service that is performed, such as meetings with customers, help desk activities and training sessions. Services are a form of products, and therefore, also contain attributes. For example, an agenda might be a quality attribute of a meeting.

A process is the set of activities that is performed to produce a product. Quality is achieved through processes. Processes have the advantage of being able to replicate a product time and time again. Even in data processing, the process is able to replicate similar products with the same quality characteristics.

Quality Assurance (QA) is associated with a process. Once processes are consistent, they can "assure" that the same level of quality will be incorporated into each product produced by that process.

Quality Control
Quality Control (QC) is defined as the processes and methods used to compare product quality to requirements and applicable standards, and the action taken when a nonconformance is detected.  QC uses reviews and testing to focus on the detection and correction of defects before shipment of products.

Quality Control should be the responsibility of the organizational unit producing the product and should be integrated into the work activities. Ideally the same group that builds the product performs the control function; however, some organizations establish a separate group or department to check the product.

Impediments to QC include the following:
  • Quality Control is often viewed as a police action
  • IT is often considered an art
  • Unclear or ineffective standards and processes
  • Lack of process training


Quality Assurance
Quality Assurance (QA) is the set of activities (including facilitation, training, measurement and analysis) needed to provide adequate confidence that processes are established and continuously improved in order to produce products or services that conform to requirements and are fit for use.

QA is a staff function that prevents problems by heading them off, and by advising restraint and redirection at the proper time. It is also a catalytic function that should promote quality concepts, and encourage quality attitudes and discipline on the part of management and workers. Successful QA managers know how to make people quality conscious and to make them recognize the personal and organizational benefits of quality.

The major impediments to QA come from management, which is typically results oriented, and sees little need for a function that emphasizes managing and controlling processes. Thus, many of the impediments to QA are associated with processes, and include the following:

  • Management does not insist on compliance to processes
  • Workers are not convinced of the value of processes
  • Processes become obsolete
  • Processes are difficult to use
  • Workers lack training in processes
  • Processes are not measurable
  • Measurement can threaten employees
  • Processes do not focus on critical aspects of products

Differentiating Between Quality Control and Quality Assurance
QC is an activity that verifies whether or not the product produced meets standards. QA is an activity that establishes and evaluates the processes that produce the products. If there is no process, there is no role for QA. Assurance would determine the need for, and acquire or help install system development methodologies, estimation processes, system maintenance processes, and so forth. Once installed, QA would measure them to find weaknesses in the process and then correct those weaknesses to continually improve the processes.

It is possible to have quality control without quality assurance. For example, there might be a standard that “ALTER GO TO” statements in COBOL should not be used. Regardless of whether a program is produced using a system development process or done by an individual without a process, it could still be checked to determine whether or not “ALTER GO TOs” are in the program.


The following statements help differentiate QC from QA:
  • QC relates to a specific product or service.
  • QC verifies whether particular attributes exist, or do not exist, in a specific product or service.
  • QC identifies defects for the primary purpose of correcting defects.
  • QC is the responsibility of the worker.
  • QA helps establish processes.
  • QA sets up measurement programs to evaluate processes.
  • QA identifies weaknesses in processes and improves them.
  • QA is a management responsibility, frequently performed by a staff function.
  • QA evaluates whether or not quality control is working for the primary purpose of determining whether or not there is a weakness in the process.
  • QA is concerned with all of the products that will ever be produced by a process.
  • QA is sometimes called quality control over quality control because it evaluates whether quality control is working.
  • QA personnel should not ever perform quality control unless doing it to validate quality control is working.


Thursday, November 19, 2009

Things to think about when defining test regression scope

How much regression do we do?  How do we select the right balance?


These are the things I consider:


Recent: new features, new areas of code are more vulnerable
Core: essential functions must continue to work
Risk: some areas of an application pose more risk
Configuration sensitive: code that’s dependent on environment settings can be vulnerable
Repaired: bug fixes can introduce new issues
Chronic: some areas in an application may be perpetually sensitive to breaking

Wednesday, November 18, 2009

The Three Key Principles of Quality

Everyone is responsible for quality, but senior management must emphasize and initiate quality improvement, and then move it down through the organization to the individual employees. The following three quality principles must be in place for quality to happen:

  1. Management is responsible for quality.
Quality cannot be delegated effectively. Management must accept the responsibility for the quality of the products produced in their organization; otherwise, quality will not happen. A quality function is only a catalyst in making quality happen. The quality function assists management in building quality information systems by monitoring quality and making recommendations to management about areas where quality can be improved. As the quality function is a staff function, not management, it cannot dictate quality for the organization. Only management can make quality happen.

  1. Producers must use effective quality control. 
All of the parties and activities involved in producing a product must be involved in controlling the quality of those products. This means that the workers will be actively involved in the establishment of their own standards and procedures.

  1. Quality is a journey, not a destination.
The objective of the quality program must be continuous improvement. The end objective of the quality process must be satisfied customers.

The Quality Solution
The action that must be taken by management to make quality happen is as simple as 1-2-3:
  1. Define quality
  2. Control quality
  3. Assure quality

After management becomes committed to the quality principles, the most effective method for making these three actions happen is to establish a quality function. While a quality function is not necessary to make quality happen, quality rarely happens without adequate attention devoted to the quality objectives. As stated in the first key principle above, the quality function should be that catalytic group which initiates quality improvement programs in order to make quality happen.

Best Practices
A practice is a specific implementation of a work process. For example, a practice would be one organization’s process for estimating the amount of resources required for building a system. A Best Practice is one of the most effective practices for performing a specific process. Best Practices are normally identified by benchmarking.

Cost of Quality

The cost of quality (COQ) is the money spent beyond what it would cost to build a product right the first time. If every worker could produce defect-free products the first time, the COQ would be zero. Since this situation does not occur, there are costs associated with getting a defect-free product produced.

There are three COQ categories:
  • Prevention - Money required preventing errors and to do the job right the first time is considered prevention cost. This category includes money spent on establishing methods and procedures, training workers and planning for quality. Prevention money is all spent before the product is actually built.

  • Appraisal – Appraisal costs cover money spent to review completed products against requirements. Appraisal includes the cost of inspections, testing and reviews. This money is spent after the product or subcomponents are built but before it is shipped to the user.

  • Failure – Failure costs are all costs associated with defective products. Some failure costs involve repairing products to make them meet requirements. Others are costs generated by failures, such as the cost of operating faulty products, damage incurred by using them and the costs incurred because the product is not available. The user or customer of the organization may also experience failure costs.

The cost of building a product is comprised of the cost of production, which is the cost if the product could be built defect free, plus the three COQ categories. Added together, the production cost and COQ become the cost to build a product. The three COQ categories are sometimes called the cost of nonconformance, meaning COQ is the failure to conform to a process that enables defect-free products to be produced.

The quality function attempts to reduce the cost of quality. This is usually accomplished by increasing the prevention and/or the appraisal costs in order to reduce the failure costs more than the increase in the prevention and appraisal costs. It shows that initiating new appraisal programs such as inspections and reviews in software development, or new preventive programs such as staff training, can reduce the failure costs, which include such things as rework, so there is a net reduction in the cost to build a product.

Studies show that the COQ in IT is approximately 50% of the total cost of building a product. Of the 50% COQ, 40% is failure, 7% is appraisal, and 3% is prevention. Other studies have shown that $1 spent on appraisal costs will reduce failure costs threefold; and each dollar spent on prevention costs will reduce failure costs tenfold. Obviously, the right appraisal and prevention methods must be used to get these benefits. – Quality Assurance Institute

For example, the cost of adding unidentified requirements during system or acceptance testing is much more costly than identifying those requirements during the requirements gathering phase.  Once individuals understand the cost of "overlooking requirements" they might be more willing to use techniques such as requirements reviews, JAD sessions, and improved processes to avoid the overtime, stress, and excessive cost of building those overlooked requirements late in the development process.