Test case creation for further automation

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

1. Test must be written in a form of checklist without deep detalization;

2. Test cases have priority level (blocker/critical/major/minor) based on documented approach or on any other document;

3. Summary must be short but eligible to understand the meaning of it;

4. Each test is created for one feature testing and contains only one assert;

5. Assert can be directed on several conditions check-up, but they must happen simultaneously (without additional steps) - see document attached below for details "3. Method: DataDriven (One scenario and multiple tests on vary of preset data)"

6. Grouping of test sets must be correctly formed:

   • Unite similar tests in one

   • Do not unite different tests in one

7. Test case must not contain the chain of steps with expected result 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 (as exception test case reflected in "2. Method: One action - multiple results");

8. One test must be created for cases when there is a necessity to check several conditions but they comes simultaneously;

9. Expected result must be clearly described in test case body;

10. Use data driven approach - "one test with different input parameters" → "1 case with a 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

11. Do not use unclear test cases/expected results that address 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);

12. Test scenarios must not be a copy-paste of the requirements from SRS, they must be adapted and clearly formed.

Documented Example

Methods and examples