...
The table has a task to identify the release-specific tests to be executed.
The table assumes 3 candidate releases of SIMP (Alpha, RC1 and Final ), but should be adjusted based on the complexity of the release and bugs found during testing.
Only 2 candidate releases may be required for a SIMP patch release.
More than 3 candidate releases may be required for a SIMP major release.
Not all the tests may need to be repeated if the changes made don’t impact the test. For example, changes bug fixes to simp-extras modules won’t necessarily require full regression tests to be executed, when these modules are not exercised in the regression tests.
Stories are indicated with a <number> ID, whereas subtasks to a store are indicated with <parent number>-<child number> ID.
The Blocker field in a story is used to indicate that this story requires the listed stories to be completed before it can be done.
Stories or subtasks will be replicated based their release candidate and OS fields.
When Y appears in one of the release candidate or OS fields of a story, that story will be replicated for the permutation noted.
When just release candidate permutations or just OS permutations are noted, that story will be replicated for individual release
candidates/
OSes selected.
When both release candidate and OS permutations are listed, the story will be replicated for each OS for each release candidate.
When Y appears in one of the release candidate or OS fields of a subtask, that subtask will be replicated for the permutation noted within the story.
N, -, and a blank entry are all treated as ‘do not replicate’ indicators.
Use the Y/N Column Pre-Automated Ticket Creation. Once tickets are done, use codes above!
...