A Concise QA Process

A Concise QA Process

• 1.
  A Concise QA andTesting Process Referenced from: Rapid Software Testing by James Bach and Michael Bolton! Created by Arslan Ali Sr. Consultant – IS for Sidat Hyder Morshed Associates
• 2.
  A Concise QAProcess • Developed by James Bach, for a start-up market-driven product company with a small base of customers • This process is intended to be consistent with the principles of the Context-Driven School of testing and the Rapid Testing methodology. • Although it is not a “best practice”, He offered it as an example of how a concise QA process might look.) • This document describes the basic terminology and agreements for an agile QA process. • If these ideas don’t seem agile to you, question them, then change them. 2
• 3.
  Build Protocol Addresses theproblem of wasting time in a handoff from development to testing. 1. [When time is of the essence] Development alerts testing as soon as they know they’ll be delivering a build. 2. Development sends testing at least a bullet list describing the changes in the build. 3. Development is available to testers to answer questions about fixes or new features. 4. Development updates bug statuses in the bug tracking system. 5. Development builds the product based on version controlled code, according to a repeatable build process, stamping each build with unique version number. 6. When the build is ready, it is placed on the server. 7. Testing commits to reporting sanity test status within one hour of build delivery. 3
• 4.
  Test Cycle Protocol Addressesthe problem of diffusion of testing attention and mismatch of expectations between testing and its clients. Full cycle: All the testing required to take a releasable build about which we know nothing and qualify it for release. A full test cycle is a rare event. Normal cycle: This is either an incremental test cycle, during Feature Freeze or Code Freeze, based on testing done for earlier builds, or it’s an interrupted cycle, which ends prematurely because a new build is received, or because testing is called off. Spot cycle: This is testing done prior to receiving a formal build, at the spontaneous request of the developer, to look at some specific aspect of the product. Emergency cycle: “Quick! We need to get this fix out.” If necessary testing will drop everything and, without prior notice, can qualify a release in hours instead of days. This would be a “best effort” test process that involves more risk of not catching an important bug. 4
• 5.
  What happens ina Test Cycle? 1. Perform smoke test right away. 2. Install product in test lab. 3. Run convenient test automation. 4. Verify bug fixes. 5. Test new stuff. 6. Re-test anything suspected to be impacted by changes. 7. Periodically re-test things not tested recently. 8. Periodically re-test previously fixed bugs. 9. Perform “enabled” test activities (what recent additions or fixes make possible). 10. Revisit mystery bugs. 11. Continue previous test cycle. 12. Investigate and report problems; otherwise provide quick feedback to development. 13. Coordinate help from part-time testers. 5
• 6.
  Change Protocol Addresses theproblem of excessive retesting or failure to detect important problems late in the development cycle. Release Team: This is the person or persons who make the decision (or substantially contribute to the decision) to release the product. Typically includes development manager, test manager, product manager, and project manager. 6 There are different levels of change control because we have competing goals. We want to get the job done fast, and we want to get it done right. This calls for phased change control. Freezing allows testing to run briefer test cycles. On any real project, some of these phases may be skipped. A small release might go directly to code freeze.
• 7.
  Types of Releases Alpha:Development manages changes within itself. No externally imposed protocol. Feature Freeze: Typically begins with the delivery of a feature complete build. No new features without specific Release Team approval. Any bug fix can be made without approval. Code Freeze: Typically begins with the delivery of a release candidate. No changes of any kind can be made without specific approval by the Release Team. 7 The release team must meet periodically, perhaps every day, during freezes. They look over change requests and bugs and decide what will be done.
• 8.
  Release Protocol Addresses theproblem of messing up at the very last minute. Signoff: The release team formally decides that a particular release candidate can be shipped. Package testing: Testing performs final checks, including a virus scan, release notes review, and file version review. Final installation testing. FCS: Final customer ship. Acceptance Testing: Customer installs and tests product while testers and developers stand by to support. 8