Product QA - A test engineering perspective


Published on

Imaginea's time test product qa methodology. Our hawkeye methodology helps products get released to maker more efficiently and in lesser time. Products have to be tested with a gotomarket testing approach and thats what we specialize at.

Published in: Technology
1 Like
  • Be the first to comment

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

No notes for slide

Product QA - A test engineering perspective

  1. 1. 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
  2. 2. 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?
  3. 3. 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
  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. Our Offerings
  6. 6. Services
  7. 7. Business landscape
  8. 8. Non-testing Functions
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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