Difference between revisions of "Release Team/Creating a Smoke Test"

From Sugar Labs
Jump to: navigation, search
m (New page: {{draft}} This is a howto for creating smoke tests for various pieces of software. # Make a list of the fundamental functionalities of the product. (If this feature doesn't work, Sug...)
 
m (moved Creating a smoke test to Release Team/Creating a smoke test: creating a cluster of smoketest material under the release team)
(No difference)

Revision as of 15:11, 30 August 2009

Pencil.png NOTICE:  This page is a draft in active flux...
Please contribute to these contents and discuss issues on the discussion page.


This is a howto for creating smoke tests for various pieces of software.

  1. Make a list of the fundamental functionalities of the product. (If this feature doesn't work, Sugar should be considered fundamentally broken.)
  2. Triage the features into 3 lists.
    1. Priority 1: Without this feature, the product is unusable. (Example: If Sugar Activities don't start at all, you can't access most of the basic functionality in Sugar.)
    2. Priority 2: Without this feature, important subsets of the product are unusable. (Example: If Sugar can't connect to a Jabber server, you can't access the subset of functionality related to collaboration. However, you can access other important functionalities of Sugar; for instance, you can still run Activities and save work to your Journal.)
    3. Priority 3: This is a feature that should be working for the product to be considered working, but its failure does not cause other features to be inaccessible. (Example: Displaying the remaining battery charge is a fundamental feature; however, if it does not work, it does not affect other features in Sugar.)
  3. Come up with test cases that cover as many of the features as possible. Each test case should start and finish with the software in a neutral state. Focus on covering all the #1s first, then the #2s and #3s. At this point you should be writing at the detail necessary for you to run the tests again.
  4. Go through the test again and write instructions so that others can follow it. Have "do" instructions and "verify" instructions, and note the coverage of each test case (which features each test case verifies).