context: ...; trigger: ...; checked?: ...; edited: ...; check prerequisites:...; decision criteria:... ===> ( ‖ re-)checked
[ ] TBD
- the above test case is a master test case template
- the actual test cases can miss or combine some of its parts and use more abbreviations if needed
- the actual test cases are listed below
- -> = highlights a "test step" that changes a value of specific test param (if exist, then all other test params are considered as a precondition relatively to such step)
- N-> = Nth test step (i.e. test step number N), e.g. 1-> = 1st test step, 2-> = 2nd test step
- Legend:
- ‖
value= the value for test parameter is mentioned as existing case but intentionally de-prioritized from testing - ‖ = OR
- absence of punctuation between sub-list items in Scheme = OR
- , = AND, usually on test param values level
- ; = AND, usually on test params or test steps level
- ==> = divides test params from expected result on the right
- <== = divides test params from expected result on the left
- ... = "whatever appropriate matched, taking into account other test params and expected result", reflects the idea of "pattern matching", like in graphql, datalog, or Cypher
- bold = highlights the "key" test param value or expected result
- ⁑ = highlights the key test param value in context of applied pair wise td technique
- ‖
| context | trigger | checked? | edited | check prerequisites | decision criteria | ==> (re-)checked | Instructions (Preconditions & Steps) |
|---|---|---|---|---|---|---|---|
| checking enabled | created | "unknown" | NO edits | YES (...) | YES (...) | found |
- trace coverage to master test case
- apply pair wise to columns with currently constant values
- optimize columns (change to ... where relevant)
- add priority column to all tables
- recheck for missed test cases, thinking about most common use cases in real life, and set priorities correspondingly
- add automation column to all tables (values: SM, SP(ui‖api), IP, UP, SA(ui‖api), IA, UA)