Master Test List: Schedule and Results Log
What: A tabular format for listing the tests to be run during a testing cycle (such as Beta, System test etc.), with a place to categorize and describe each test, provide pass-fail criteria, indicate the planned run day or week; and log pass-fail test results.
Why: This format can be used as a master list on any project. It is especially useful for smaller projects, where it could be THE test plan/test case document, documenting all cases to be run while still providing a quick-reference look at what has been tested, what is left to test etc. It is formatted to be not only a plan document but serve as a good tracking document as well. On a larger project with many test cases and lots of detail per case, this table format would be most useful as a master list, with test case detail residing either later in the document as text paragraphs, or in separate documents.
The Master Test List table includes slots for specifying how a test should be run, what should be measured or observed, and what should be recorded. It also includes a place to specify pass-fail criteria. Both these fields are critical for ensuring the testing is meaningful, and that a test is not declared “passed” without an objective assessment of its results against those criteria.
How:
§ During early test planning activities, identify the major types of tests to be run.
§ Fill in the other planning information (resources, equipment needed, etc.) if you’d like to use this as your overall test plan.
§ As you get closer to the testing activity, identify logical “sets” of tests (for instance, for a particular subsystem or subset of functionality) and create sections of the test plan for them.
§ Create your list of test cases in each set, marking the test type for each as well.
§ As test case details are defined, record bulleted instructions for running the tests, measuring or observing results, and what should be recorded. Specify also the pass-fail criteria for each test case.
§ When you’re much closer to the test activity, start to slot the test sets into specific points in the testing timeline and mark their “planned date” in the Master Test List table.
§ Once testing has begun, the master list can be used weekly or daily for planning the test activities for the next time period, assigning testing responsibilities, and reviewing progress and results.
§ As the test table starts to fill up, and you get near the end of the test timeline, you can scan the right-most column to see items that have not passed, and ensure they are being addressed.
§ File the Master List as a top-level record of the testing performed.
§ Later, if issues are discovered that should have been caught during testing, you can go back to the master list and determine what was missing from the plan, and document the missing tests for next time.
§ The master list can also be used when a small enhancement is made to the same system/ product; tests from the list can be used as “regression” tests to ensure the new enhancement didn’t break any existing functionality.
Project ______: Master Test List for [testing phase]
Purpose: [State which testing phase this applies to, and the purpose of the testing.]
Test Types:
This test phase will include the following types of tests [add types/ edit for your project]
§ Functional (feature): Verification that the system meets its functional/feature requirements
§ Load and Performance: Testing to confirm that performance objectives are satisfied. Includes accuracy testing.
§ Configuration and interoperability: Testing to assure that all functions work under all combinations, on all required hardware platforms, with all necessary software versions, etc.
§ Stress: Testing which attempts to break the system by stressing all of its resources
§ Environmental: Testing to ensure the system operates properly throughout the specified range (temperature, etc.)
§ Recovery and Error Handling: Testing to confirm that the system recovers from hardware and/or software malfunctions without losing data or control, or that it follows the error handling requirements defined for the product.
§ Usability: Testing to assure the user interface is appropriate to the audience; that the system is serviceable, maintainable etc.
§ Regulatory: Testing to assure the system meets all regulatory requirements (e.g. safety, emissions, etc.)
§ Etc.
Continued next page
(Use these sections if you are making this your complete test plan document)
High-level Testing timeline:
Task / Date/ Date rangeTest environment preparation:
Test start:
First test data and defect log review
Functional tests
Performance and stress tests
Environmental/ regulatory tests
Final regression testing before ship
Personnel/ Resources involved:
Identify all personnel to be involved directly in the testing, or in critical supporting roles. Define the responsibilities assigned to each.
Who / Co. / Role / Responsibility / Contact # / Back-up contactEquipment, supplies, facilities:
Identify all tools, facilities, test equipment required and who is expected to provide them.
Problem Recording, Issues Management and Escalation, Rework, and Resolution:
Define the mechanism to be used for problem recording and resolution, escalation of issues if necessary, and recording of associated changes to the system. Define the process for rework, review, and retest of any element which needs modification. This process must include sufficient retest to verify that any modifications have not impacted other functions already tested.
End of optional test plan introduction material
***** Master Test List table starts on the following page *****
Master Test List: Schedule and Results LogProject ______: Master Test List for [testing phase]
[Brief description of rationale for this test set]
Set 1: [name of this set of tests]Case # / Type * / Description / What to run, measure, record / Pass criteria / Date Planned / History: Date Run, Pass / Fail / Date Passed
1 / Functional
2 / Functional
3 / Functional
4 / Performance
5 / Stress
Project ______: Master Test List for [testing phase]
[Brief description of rationale for this test set]
Set 2: [name of this set of tests]Case # / Type * / Description / What to run, measure, record / Pass criteria / Date Planned / History: Date Run, Pass / Fail / Date Passed
Project ______: Master Test List for [testing phase]
[Brief description of rationale for this test set]
Environmental, Other RegulatoryCase # / Type * / Description / What to run, measure, record / Pass criteria / Date Planned / History: Date Run, Pass / Fail / Date Passed
Project ______: Master Test List for [testing phase]
[Brief description of rationale for this test set]
REGRESSION TESTS before shipCase # / Type * / Description / What to run, measure, record / Pass criteria / Date Planned / Date Run/ Passed? / Date Passed