1. A Concise
QA and Testing 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 QA Process
• 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 the problem 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
Addresses the 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 in a 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 the problem 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 the problem 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