Test should be created within the ticket of a story. It represents one test case, with one or more steps. A story should have at least one Test linked to it, but it could be more depending on the story. These Tests should be added to a Test Plan at the start of a sprint. A Test also has different statusses:
The Test itself should not be linked to a sprint, but the Test Plan of which this test is a part of should be.
The naming of the Test should reflect the naming of the corresponding story, but edited with the word "Test" as to make clear this is specially for testing. For example, if the title of the story is "Improve the interface" the Test should be named "Test Improve the interface"
Pre-Conditions are generic steps that are not necessarily part of the actual Test case, but mostly used as some setup conditions before the real Test can start. These steps are reusable and may be linked to multiple steps. These pre condition should never be linked to any sprint.
To be created at the start of each sprint and linked to that sprint. It is just needed to create an empty Test Plan, which can be filled with Tests created for each story in the sprint. The name should reflect the naming of the sprint, for example "DMS Test Plan sprint 1", "DMS Test Plan sprint 2" etc.
A Test Set is a collection of Tests that can be linked to each other for organizing purposes. These can be matched by subject or a specific part of the application. Using Test Sets can make looking up and re-using existing tests more easy and manageable. A Test can be linked to multiple Test Sets. It should be clear by naming the Test Set what the common factor of these Tests are, for examle "Test Set - parts master interface (DLITMPRT)" for all Tests regarding the parts master interface, regardless which story. A Test Set should not be linked to any sprint.
Do we need / want repositories. If yes, what status, what naming convention etc.
At this moment there will be no Tests yet in this Test Plan. When scrolling down this Edit screen, it is possible to add this Test Plan to the current screen:
For each story in this sprint it is possible to create one or more Tests.
This will open up a pop up screen where various setups can be created. At this point the naming is important (a reference to the actual story), checking that the the linked story is correct (under Link Issues) and the the Test Plan is added (under Test Plans):
Optionally a Test Set can be linked here, for example to link this Test to other tests for the same interface. Another option is to add Pre Conditions, that should already have been pre defined.
This test should not be linked to the sprint, so make sure the correct Test Plan is added in order for this Test to be executed once the development of the story is done.
When the Test tickets have been created in step 2, it is possible to define the actual Test case in the newly created Test ticket. As many steps as possible can be added to each Test:
Within each step there is room for the actual action where a description is to be entered about the Test case. Test data (conditions) can be added in the second space. And in the last space there is a space for the expected results, to be extracted from the requirements and functional documentation. At this point it is also a possibility that questions about these requirements will come up, so this would also be a good time to get some extra confirmation from the PO or BA in case of doubts about the expected results.
After all test cases/test steps have been created and the tests have good coverage for this story, the Test ticket can be set to done, in order to know that this Test can be executed as soon as development and reviewing is done for the story.
Once all the Test tickets have been created it is possible to get an overview of their status by looking at the XRay Test Plan Board just to see which Test tickets should still be completed.
If all Test tickets are done, it is possible to create a Test Execution ticket for all of them in once from within the Test Plan ticket:
Once All Tests has been selected, a new ticket will be created with the Test Execution of all the tickets. It is of course also possible to add one Test at the time to the execution ticket, so it is not necessary to wait until all Tests are done.
It is important to check that just as with the Test Plan, this Test Execution is linked to the current sprint.
5. Executing Tests
TM creates Tests (issue type) for all stories included into Sprint and associates them with Test Plan.
Tests should be created from the story:
2. When Tester starts work with the story, he/she creates Test Design for the story within the associated Test
Tester add test steps with all necessary data and Expected Results
3. The development is done and story is deployed for testing, Tester goes to the story and creates Test Execution for the newly created Test
4. To start test execution click icon "View runs" from the Story:
or click on "Execute in" in Test issue:
Test run will open in a new tab.
If you don't see the "View runs" icons in the Story, open the Test, scroll down to Executions. There is a Play (Run) button near each execution.
Click it and select Execute:
Please note: to be able to run the execution, it should be assigned to you. Otherwise you will not see the Execute button.
5. Tester executes all steps manually on test env and set the status for each step (Pass/Fail) within created Test Execution
Bugs should be associated with test step if found
6. Each Test Execution should be added to Test Plan by Tester
7. If bug was found and test step is failed, new Test Execution should be created after bug fix. Steps 3-6 should be repeated
8. Test is completed when all test steps are green for latest Test Execution
Planning per sprint
Issue type visible on board: Plan and Plan Execution
Use Switch sprint at the top to filter on a specific sprint.
