Page History
...
By having the Test Plan being handled as an artifact to be handled in the scope of the sprint, similar to what happens with Stories, Tasks, Bugs and other issue types, you deal with it in the same way as you deal with other entities: it is something that you have to address/manage during the sprint. You can even take advantage of the workflow status of the Test Plan as a means to identify in which status it is (e.g. if it is in "To Do", "In Progress" or "Done").
...
Sometimes, you may prefer to distinguish regression testing (RT) from non-regression testing (NRT), for several reasons.
ThusTo do so, you can create one Test Plan containing all Tests that cover the "requirements" (i.e. user stories) and use it to track their progress along with another distinct Test Plan for all the regression related tests.
...
Of course, this may lead to some additional management overhead and thus you should choose wisely the number and what how many Test Plans exactly you want to have.
...
This may provide a quick way for you to schedule the execution of certain Tests; , and you can also link that Sub Test Execution to an existing Test Plan.
Sub-Test Executions mimic the creation of other development-related sub-tasks but in this case, for testing (execution only) concerns.
Overall, Sub-Test Executions provide...:
- ability to track the progress of the Test Execution in the Agile board, by seeing it in - context with the parent Story
- ability to count the time estimates of the Sub-Test Executions within the overall time estimate at the parent Story
- ability to optionally restrict workflow transition on the parent requirement based on the workflow status of the related sub-tasks (e.g. , allow transition of the Story to "closed" only if the Sub-Test Executions are also "closed")
Using Sub-Test Executions may be a straightforward approach to define the "task(s)" of executing the Tests related with to some Story. Thus, you can handle them similarly to any other development related sub-task in the context of the Story (e.g. performance analysis, visual design): assign them, estimate/log work on them, implement workflows on them to know whenever they're completed or need review.
...
| Info | ||
|---|---|---|
| ||
To be clear, you don't have to use Sub-Test Executions. However, as mentioned above they may provide some interesting benefits for some specific use cases. (mention what the benefits would be) However, if you decide to also use Sub-Test Executions, please always link them to the proper Test Plan so you can track their results at an a higher level: at the Test Plan level. That way, you will be able to always track the progress from the Test Plan point-of-view. |
Tracking progress in Agile/Scrum based boards
As shown in in the Agile Enhancements page, you can configure your Agile Scrum board to show immediate feedback about:
- coverage status of the user stories (or other entities that you cover with tests); note that this status includes real-time feedback about the latest test results
- progress of Test Plans (if you want, you may include Test Plans in the board)
- progress of Test Executions Executions (if you want, you may include Test Executions in the board)
Including It's not recommended to Include in the board Test Executions coming from automated testing (i.e. during CI), may not be recommended as it will overload the board and not provide any real added value. Instead, you may include only Test Plan(s) as a means to group and show the consolidated results coming from automation.
...
You may have a look at the previous instructions for Scrum teams as most of it can also be applied in to Kanban teams.
In Kanban, you're limiting the amount of WIP issues in a given state, namely, the ones that are in testing. Because you're not dividing your release into several periods of time, as you do with Scrum, you can manage it as if the period would embrace the time frame of the release.
Thus, you can have a Test Plan to track the Tests related with to the features being addressed on the Kanban board. You may complement it with additional Test Plans, namely, for tracking the regression testing. It may be a good approach to have the Test Plan with regression tests, or smoke tests, as an independent Test Plan, so it is more apparent if regression is occurring or not.
...
- We're not really adopting Scrum perfectly... can we use these approaches in our case?
- Yes, you may follow these same principles and adapt them to your methodology.
- We have a hardening/clean-up sprint where we wish to test thoroughly, including deep regression testing. How can this be handled?
- Hardening sprints are normally a sign that Agile is not fully being embraced. Having said that, you can have a Test Plan to track the testing performed in the scope of that sprint, adding all Tests related with user stories and other issues "implemented" on previous sprints, and thus consider the results performed in the scope of this Test Plans as being the relevant ones
- Are Test Plans, Test Executions or Sub-Test Executions child issues of an Agile board? In other words, do they belong to some Agile board?
- No. All those issues , first of all, belong to some project. They can optionally be assigned to a release (through the FixVersion/s field) and to a sprint (through the Sprint custom field).
- A different thing is showing whatever issues you want in your existing boards; as those entities are implemented as issues, you can configure boards to show them. In fact, the same issues can be included (i.e. shown) in different boards.
...