Product QA – A Test Engineering Perspective
E N S U R I N G P R O D U C T S A R E T E S T E D T H E
W A Y T H E Y W I L L B E U S E D
Copyright (c) 2009, Pramati Technologies Private Limited. Imaginea is a Pramati business. All
trade names and trade marks are owned by their respective owners
11/4/2009 1

Product QA: Why it is Tough
1. Product is more than software
• Software application
• Platform and variations
• Documentation: online help, manuals, tech briefs, examples,
training
• Add-ins and third party product integrations
• Installation experience
• Handling upgrades and updates
2. Quality is more than lack of bugs
• Does it solve the problem when it works?
• Is it practical to use? Is it designed for efficient use?
• Does it keep working or works only under ideal conditions?
• Is it economical to build, maintain and respond rapidly to
customer/user needs?

Role of QA in Product Company
• QA is everything you do to minimize risk of failure and
promote excellence
• Help producing products that satisfy target customer
base
• Broad functions of QA
– Risk management: release planning, release approval
– Bring customer involvement: early release programs
– Act as skillful developers: mimic tough customer!
– Process definition and improvement
– Inspection and testing
– Experience-based improvement: contribute to product
definition, many finer points
• Should play an important role throughout The Life of a
Product

Hawk-Eye Methodology-Precision Delivered
QA Planning
Test Suite Design
Process Definition
Design Review
Product Definition
Inputs Planning 1 2 Design
Test Development
Process Improvement 6 3
Post-Release Coding
5 4 Code Review
Release Testing
QA Certification
Test Execution
Release Inspection Risk Assessment
Early Release
Program

Our Offerings

Services

Business landscape

Non-testing Functions

QA Planning
• What QA is required to do
• QA procedures, expectations from other teams
• Effort estimation and team planning
• Resource planning, tools and software
procurement

Process Definition & Improvement
• Assessment of the state of the processes
• Setting process goals and reviewing
• Recommendations for improvement with
justification
• Action plan for implementing improvements

Test Suite Design
• Design the tests in parallel to software design
• Tests need organization into independent test
suites
• Build the tests before you build the software
• If you find a bug, write a test that proves the bug
exists, fix the bug and then rerun the test to
prove it is fixed

Test Suite Design Review
• Goal: Clarification and accept/reject design
decisions
• Starts with a presentation of the design for the
component/module to a selected panel of
developers
• Peer review is commonly used, with most
relevant engineers from other parts of the
product included
• Discussion and coordination of comments
incorporation

Check-in Review & Code Walkthrough
• Check-in review done with peers of the dev team
– Including new features and bug fixes
• Code walkthrough by dev across streams,
including QA
– review meeting with prepared participants
– Sample source files are selected for review
• Focus is on finding defects, before they slip
through to testing phases
– Lower costs by catching them early

Early Release Programs
• Need to ensure smooth porting of current
customers
• Test ISV applications available internally
• Public program to increase the test base
– Alpha and Beta testing

Release Readiness
• QA evaluates quality, independent of developers
– Developers should not determine how much quality is
sufficient
• QA acts as internal customers and verifies
release readiness