Page History
You have specified your Tests and organized them using Test Sets or using the Test Repository and now . Now, you want to know how to address properly the planning phase of your testing, right?
In fact, you You may start by creating a Test Plan and , then create the Tests, and then add those Tests to the Test Plan.
Planning your testing is also dependant dependent on the methodology and process you're adopting.
Some usage examples follow next and feel Below are some planning examples. Feel free to adapt these to your own internal process , the in a way that best fits best your team.
| Table of Contents |
|---|
...
Instead of creating one Test Plan for your " release", you may create multiple Test Plans to track different Tests.
This may be useful if you wish want to have clear visibility of how certain groups of Tests are progressing.
Some examples of creating You may create different Test Plans:
- for the Tests related to new features related Tests
- for regression testing (i.e., for Tests related with features implemented in previous versions)
- for security-related Tests
- for performance-related Tests
- for conformance compliance-related Tests
- for non-functional Tests
...
| Info | ||
|---|---|---|
| ||
This approach is independent of the methodology being used. This means you can follow You can use the tips described next for the different methodologies and extend them with these tips, in order to next to extend your methodology and gain additional visibility over certain Tests. |
...
If you're following Agile, namely particularly Scrum, you'll have sprints of one or more weeks, where each one . Each sprint represents one iteration where until at the end, you have a shippable product. Testing can occur hopefuly during the period of the sprint or more closely to the end of it. In any case, you can have a Test Plan per sprint to track the results of the Tests you want to execute, including the ones that validate the features implemented in that sprint. Besides this, you may also want to have a Test Plan related with for regression testing to ensure you're not braking breaking anything in that sprint.
| Info | ||
|---|---|---|
| ||
A sprint is a more manageable way of dividing the complexity of an entire release. A sprint has a short, well-defined time period. |
Kanban
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 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.
Waterfall
In this scenario, testing is done as a separate phase at the end of development. From the During testing, bugs may be found, which will lead to go be directed back to the requirements analysis/development, . You wait for changes/fixes to be made, and then test it once again.
...
In this approach, a release is somehow split in some several internal mini-releases, with subsets of the features implemented and it may be . It is assumed that some of these features may not be complete/stable/finished.
Each intermediate release may have one specific Test Plan as a way to track the Tests and their results, made in the context of the intermediate release. The Test Executions made in the context of each of these Test Plans can also be associated with a more broader Test Plan, so their results would also get reflected in the a broader Test Plansense.
In sum, you can simply create one Test Plan for tracking all the Tests you wish want to validate in that version along with additional Test Plans, one per iteration/intermediate release. Then, you need to assure ensure that all Test Executions created in the context of your intermediate release's Test Plan are also reflected in the "globalmaster" Test Plan.