Process Guidelines V2


Published on

Imaginea's Test engineering shares its process guideliness, best practices and recommedations for effective Product testing. Ensures software products behave the way they are supposed to.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Process Guidelines V2

  1. 1. 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
  2. 2. 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”
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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)
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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]
  12. 12. 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]
  13. 13. 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]
  14. 14. 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
  15. 15. Thank you i n f o @ i m a g i n e a . c o m