Our new QA section
explains how to make
your Website work the
way you need it to!
Fonts.com
 

2008


Home Page
Feature Archive
A&I Column Archive
Production Tools
State Marketing Data
US Marketing Data
World Marketing
Classifieds
Service Directory
Quality Assurance
3D Printing

Subscribe to Advertising & Marketing Review!
Contact Ken Custer at 303-277-9840.


QA Documentation and the Software Development Life Cycle


By G.E. Morris

Software development proceeds through a series of stages commonly called the software development life cycle, or SDLC for short.

Consciously or not, every software product, whether application or Website, goes through these stages. The more conscious you are of the stages, the more successful the final product is likely to be.

The chart below illustrates the SDLC stages and the role QA should have in each stage. Until fairly recently QA was usually not involved until the alpha stage, when actual testing could begin. The compressed timeframe most software is now developed in requires that QA be involved in the earliest stages of the product's SDLC, and that by the time the first alpha build is available, all test documents, QA staff, and test environments are in place to begin testing at the earliest opportunity.


Stage Description

QA Input

Documents

Concept

The idea for the application is defined. A general idea of the resources required to test the product is determined.

A product proposal is created for management to approve or reject.

Requirements analysis

User requirements are determined and documented. Exact QA resources required for testing are determined, based on the requirements doc.

A requirements document created which defines all features and expected behavior.

Developmental

The first semi-functional version of the application is available for testing, mostly done at the unit level by engineers. Resources are acquired and the QA environment is configured and tested.

A test plan is created based on the requirements document.

Alpha

The first version usually released to QA, feature incomplete and not necessarily stable, but testable. The specific steps to test all features are determined and full scale testing is begun.

Defects are tracked and assigned to developers. Test cases created based on the test plan. Defects are entered in the defect racking system.

Beta

Feature complete and stable. At this point, development is exclusively targeted at fixing defects. Fixed bugs should outnumber new and open bugs. Defects continue to be found & reported and fixes are verified or rejected.

Reports are created showing the ratio of new/open defects to fixed closed defects.

GMC (Golden Master Candidate)

Final build Candidate - all severity 1 and 2 defects are retested and verified fixed. Severity 3 and 4 defects are tested to make sure the extent of the problem is known.

Reports document that shows all severity 1 and 2 bugs are verified fixed.

GM (Golden Master)

Final build all severity 1 and 2 defects are fixed. Severity 3 and 4 defects are understood. QA signs off on the product as meeting all performance and functionality requirements.

An errata sheet is created and made available to users which lists all known remaining unfixed defects.




For more advertising and marketing help, news, resources and information visit our Home Page.


Back to top



QA and the Software Development Lifecycle

CMMI Levels

Writing Repeatable Test Cases

Writing Thorough Test Cases

Writing Product Requirement Documents

Basing Test Cases on Requirements Documents

Test Case Formats

Multipart Test Cases



Constant Contact -- FREE Email Marketing

null