Software QA FYI - SQAFYI

Going Beyond QA: Total Product Readiness

By: Douglas G. Thacker

The successful release of software requires more than just testing to ensure the product functions properly; success is also defined by how prepared the product is for advertisement, delivery, installation, training, support, etc. In this paper, we’ll discuss how testing can be expanded to cover all aspects of Total Product Readiness (TPR). You’ll be able to verify that each of these vital components has been properly planned and prepared for during the product development cycle. In this paper we will discuss:
· How to apply the Total Product Readiness process
· The key areas to include in the process
· The benefits of Total Product Readiness to your organization
With Total Product Readiness you can better ensure the successful introduction, end user experience, and supportability of any product.

The primary focus of software quality professionals has typically been producing defect-free products through rigorous testing. Indeed, looking at the presentations at the StarEast (Software Testing, Analysis and Review) 2002 conference this spring, a majority of them emphasize testing (testing methods, testing tools, test automation, web testing, etc).

I have been involved with software quality for about four years at Liberty Mutual. The quality process we put in place there includes traditional testing, but also encompasses other elements to ensure that our end users have a positive overall experience with any product entering our production environment. As I read articles in software quality publications and attend events like the StarEast conference, I began to realize that our approach to total product readiness is not a common approach in the software quality community. This surprised me, because the concept of total product readiness is very straight forward, fairly easy to implement, and produces significant benefits to an organization. Therefore, when SQE put out a call for papers, asking for success stories to share with other software quality professionals, I felt that our successful total product readiness program was that story.

What is Total Product Readiness?
Consider this. If you develop software, thoroughly test it, and deploy it to your customers/end users, will they be satisfied if:
· they don’t know how to install it?
· they don’t know how to use it?
· the help desk doesn’t know how to support it?

Will your company or I/S organization be happy if the software product:
· clogs your network with excessive traffic?
· violates security policies or standards?
· significantly increases the volume of email through your servers?

If your answer is ‘no’ to either of these questions, then perhaps it time to consider Total Product Readiness (TPR).
So, what is Total Product Readiness? I define it as:

The process of validating that a product is sufficiently prepared for advertisement, delivery, installation, training, support, etc. to ensure the successful introduction, enduser experience and supportability of the product.

The Total Product Readiness (TPR) process should be the final step prior to production release of software products. Therefore it is expected that normal product development life cycle is followed prior to entry into the TPR process (unit testing, integration testing, system testing, acceptance testing, etc.). It is also expected that all preparation for the product’s advertisement, delivery, installation, training, support, etc. has been completed prior to entry into the TPR process. The TPR process is not meant to be a “working” process where product readiness is completed, but rather, a checkpoint to ensure that the preparation has been completed as part of up-stream processes.

There are no “right” ways of implementing Total Product Readiness. Each organization has it’s own processes, it’s own policies to uphold, and it’s own values of what is important. What is important for one organization to include in a Total Product Readiness process may not be important to others. However, I believe there are some common components that should be included:

· Independent Test Lab
· Network
· Help Desk
· Communications/Training
· I/S Security
· Software Distribution Services
· Operations

Our implementation of Total Product Readiness at Liberty Mutual is designed for products to be implemented and used by internal users within the company. As such, we also incorporate components into our process for our deployment team, break/fix team, level 2 support team and executive support team. Total Product Readiness could also be easily be implemented in organizations providing software to external customers, and they may choose to incorporate other components to suit their processes.

A key factor to the success of any Total Product Readiness program, regardless of how it’s implemented, is the support and commitment of the organization’s senior management.

How is Total Product Readiness Implemented?
Software products that are entered into the Total Product Readiness process are reviewed by a team of representatives from each of the departments who have a stake in the product’s implementation. Each team representative has a signoff on each product, and no product can be certified for production release without signoff from each team representative.

In the next section I will discuss the role of each team representative. But first I will describe how the TPR process works, the role of the product sponsor and the TPR Administrator. Please refer to Figure (1) for a process flow chart of a typical TPR implementation.

Product Sponsor
The product sponsor is the person introduces the software product into the TPR process, and is ultimately responsible for getting the product TPR certified and implemented into the production environment. The sponsor must be intimately familiar with the product and should be involved with the product throughout it’s testing and implementation planning. The sponsor introduces their product to the TPR team, works proactively with each of the TPR team members to obtain their signoffs, answers questions and resolve issues that come up during the certification process.

TPR Administration
At the center of the process is TPR Administration. The administrators keep the track of all activity within TPR. Their primary role is receiving the entries from the sponsors, processing the entries and distributing them to the TPR Team, facilitating communication between sponsors and team representatives, as well as any necessary review meetings, collecting and keeping track of team signoffs, and exiting products once all the signoffs have been obtained. TPR Administrators also find themselves tracking and expediting issues, educating sponsors on the process, and reporting various statuses to management.

Full article...

Other Resource

... to read more articles, visit

Going Beyond QA: Total Product Readiness