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
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
· Help Desk
· I/S Security
· Software Distribution Services
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.
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.
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.
... to read more articles, visit http://sqa.fyicenter.com/art/