Process Guidelines

Process Strategy and Guidelines for a better product

Building Blocks Mission - Work towards ensuring our customer’s products are effectively used 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. Values - Customer’s Success is QLab’s Success - and so is Pramati’s.

Key Assumptions Intended client is a product firm/ISV who has outsourced/co-sourced product QA to Pramati QLabs QLabs is in a position to suggest and improve an existing QA process/ propose and set up the QA process for an effective engagement QLabs will always work towards being an extended arm of the product and its success rather than just offering a testing service To achieve over all product quality, QLabs can proactively propose a 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 5 4 3 2 1 6 Planning Design Coding Testing Release Post-Release Process Definition Process Improvement QA Planning Risk Assessment QA Certification Release Inspection Test Development Test Suite Design Product Definition Inputs Early Release Program Test Execution Code Review Design Review

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, QLabs: Plans and Defines Communication methodology Communication frequency Escalation methodology Plans and Identifies Key stake holders Functional and technical leaders Knowledge sharers

Teams ’n’ Customers – Proactive Engagement (Together we win) (contd..) 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 )

Teams ’n’ Customers – Proactive Engagement (Together we win) (contd..) 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 take aways for end to end ownership It’s a Product and not a Project 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

Key Cross Functional responsibilities and take aways for end to end ownership 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 Go-To-Market testing )

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 GoToMarket 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]

Excellence in Delivery (contd..) 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]

Excellence in Delivery (contd..) 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

Process Guidelines

More Related Content

What's hot (20)

Similar to Process Guidelines (20)

Recently uploaded (20)

Process Guidelines