Process Guidelines V2

Process Strategy and Guidelines for a better
product

A T E S T E N G I N E E R I N G P E R S P E C T I V E

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

Building Blocks

 Mission
“Work towards ensuring our customer’s products
are used, usable easily and effectively by their end
customers”

 Vision
“To be the preferred testing partner of excellence
for product ISV’s and enterprises in the chosen
markets and technologies. Provide best in class,
innovative testing services delivered on time, every
time and any time”

Key Assumptions

• Intended client is a product firm/ISV who has
outsourced/co-sourced product QA to Pramati’s Imaginea
• Imaginea is in a position to suggest and improve an existing
QA process/ propose and set up the QA process for an
effective engagement
• Imaginea will always working towards being an extended
arm of the product and its success rather than just offering a
testing service
• To achieve over all product quality Imaginea can proactively
propose for few mandatory things from the customer
• Believe in process as a tool for improvement in every aspect of
our work rather than a step by step tutorial
• Process is not a hindrance to innovation, but a handle to
increased customer satisfaction

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

Process Strategy and guidelines- Focal Points
• Teams’n’Customers – Proactive Engagement (Together we win)
 Defined communication
 Assigned ownerships
 Refined delivery
• Cross Functional Responsibilities
 Product is not just about writing code, its more than that
 Respect each other for what they do as part of the PDLC
• Prevention is better than cure
 QA has to be the eyes and ears of the product
 QA is the first customer (hear and understand what they say)
 Bugs and reports are not enemies/pointers towards development
• Excellence in Delivery
 Own what you released
 Metrics for Improvement
 Report what you did, Analyze what went wrong and Improve
• Key Value Adds
 Extended arm in product testing

Teams’n’Customers – Proactive Engagement
(Together we win)

Apart from the Project Schedules and Plans
• Plan and Define communication methodology
• Plan and Define communication frequency
• Plan and Define escalation methodology
• Plan and Identify Key stake holders
• Plan and Identify functional and technical leaders
• Plan and Identify Knowledge sharers

Teams’n’Customers – Proactive Engagement
(Together we win)
• Increased Peer to Peer Engagement through FeatureSpot meetings once in 2
weeks at least/ whenever a new feature is being developed/planned
• Developers and QA to interact more on feature discussions through a common
interface.
• Develops bonding, respect and sense of product ownership
• Once/Twice in a month cross functional call to get the sense of market and
customer requirements (if possible)
• Bug severity levels, descriptions and escalation procedures to be defined before
testing takes off (protocol/modus operandi)
• Bug owners from QA and Dev side module/feature wise to be identified before
testing takes off (Ownership driven)
• Bug assigners from conflict resolution owners to be identified before testing
takes off (ownership driven and effective communication)
-- Technical aspects of the bug (Engineering responsibility both Dev and QA)
-- Functional aspects of the bug (Product Management responsibility with Dev
and QA)

Key Cross Functional responsibilities and
takeaways for end to end ownership

 Drive down the Bare need of the product and its positioning
 Product Management/product marketing to provide business value and use case
that drives the product into the market
 Offshore QA to understand who, where and why the product is being used
 Drive in the performance expectations of the product to ensure it works the way it
should rather than the way it can
 Product Management/product marketing to provide desired performance
benchmarks against which (at the beginning of the product dev cycle)
 Offshore QA would ascertain and provide results to ensure reliability
 Dev/Architecture/Engineering to signoff the benchmarks provided by the product
management and share the unit testing results to offshore QA towards measuring
the performance (after code freeze)
 Offshore QA would share the performance benchmark testing plan and strategy
and share the key test results and trends (before GoToMarket testing)
 It’s a Product and not a Project

Prevention is better than Cure

• Bugs are not our enemies neither they are a direct
measure of the work we do.
• Dev not to take bugs as personal pointers
• QA not to make bugs are the only measure of their
credibility
• Dev to see they find as many bugs as QA would have
[Increases QA scope]
• QA to see they find as many bugs as Customer would
have [Increases product quality scope]
• An effective Dev-QA is more important than
individual Dev and QA

Excellence in Delivery
 Own what you released
• Do not be in a hurry to release just because the date is there/it has reached
• Is it really ready (Introspect and think like the end user) ??
• Account for this testing in your Project Plan rather than Panic
• Account for User Driven Go-to-Market testing for a specific period of
time post functional sign
 Separate use cases will be written/can be provided
 Identified use cases/work flows/scenarios will be demoed one last
time by QA before letting go to market
 Product Management/Marketing to sign off both the scenarios
and demo
 Will be tested on a purely fresh environment rather than the same
one that was used for individual feature testing
 Its all about meeting the functional needs in its simplest
form than being glossy and complex

Excellence in Delivery (contd..)

 Some Metrics and related process guidelines
– Define bug severity levels and descriptions at the beginning
– Number of Sev-1 and Sev-2 bugs that can be allowed to be open
for Ready to Go to be decided in advance
– Number of Sev-1 and Sev-2 bugs to be allowed to be open for
beta release to decided in advance
– Number of Sev-1 and Sev-2 bugs that can be converted/down
graded to Sev-3’s and Enhancements to be decided in advance
– Effective Bug Filing rate –> Direct measure of offshore QA’s
credibility (Number of bugs posted – No.of invalid bugs)
– The lesser the Junk bugs the more its effective [Penny saved is
worth more than a penny earned]


• Enhancement Quotient
– More number of valid enhancements that QA provides and
agreed upon proves the way QA thinks from a market and
customer stand point- Key Differentiator towards product
ownership rather than project ownership
– Enhancements filed by QA which go in as features in the next
releases/ which result in product enrichment must be recognized
and rewarded too [Motivation and Recognition]
• Quality is more important than Quantity
– 1 Quality bug is better than 10 which convey the same

.. And Many More Metrics can be worked out both on Dev and QA front [Numbers
should reflect the stage and status, not the damage and demotivation]


• Automated, Standardized and Centralized reporting
– Reports at every mile stone [Agreed upon]
– Reports at regular intervals [Agreed upon]
– Publish to all the stake holders [Agreed upon]
– Bug triage meetings and reports [Archive and publish]
– Report and analyze Bug trends severity wise with a correlation to
modules and over all functionality rather than bugs in its
individuality [Archive and publish]
– Performance and Benchmark reports [Archive and publish]

Key Value Adds- Extended arm in product
testing
• Trends and Improvements [Post Mortem]
• List of enhancements and Open bugs [Release
notes and next release]
• Contribute to beta programs and product launch
demos
• Help Professional services, support and sales
teams with product training if required

Thank you
i n f o @ i m a g i n e a . c o m

Process Guidelines V2

More Related Content

What's hot (19)

Similar to Process Guidelines V2 (20)

More from Imaginea (20)

Recently uploaded (20)

Process Guidelines V2