This document establishes guidelines for creating concise and prioritized test cases in checklist format, ensuring clarity and effective testing. It emphasizes single-assert test cases, logical grouping, data-driven approaches, and clearly defined expected results.
Basic Rules
-
The test must be written in the form of a checklist without deep detail.
-
Test cases have priority level (blocker/critical/major/minor) based on the documented approach or on any other document.
-
The summary must be short but clear to understand its meaning.
-
Each test is created for one feature testing and contains only one assertion.
-
Assert can be directed on several conditions, but they must happen simultaneously (without additional steps). See the document attached below for details.
-
Grouping of test sets must be correctly formed:
-
Unite similar tests in one
-
Do not unite different tests in one
-
-
Test cases must not contain a chain of steps with expected results for them (in a way "step-result" → "step-result" → "step-result"); such test cases must be separated into several test cases with different pre-conditions. See the document attached below for details.
-
One test must be created for cases when there is a necessity to check several conditions, but they come simultaneously.
-
The expected result must be clearly described in the test case body.
-
Use a data-driven approach: "one test with different input parameters" → "1 case with tabular data inside" (applied for cases directed on different validation rules check-up, describe the table as a table with columns: value - isValid - errorMessageText).
End State
-
Do not use unclear test cases/expected results that refer to other ones, such as "Must be worked as in Story "XXX" on iPnone6" (unclear expected result) or "Page layout must be looked pretty enough" (as well, the expected result is unclear).
-
Test scenarios must not be a copy-paste of the requirements from the SRS; they must be adapted and clearly formed.
