We recently went through the whole theory on the purpose of such document. We hopefully proved to each tester that such a document is more than a list of features to be tested. A good plan vastly reduces the risks associated with the whole process. It is time to present you with our sample test plan document. In the following article you can read our test plan example as well as get a sample template so you can write a similar one on your own.
Before we do that, we need an example app, so welcome do BestAdPortal! (disclaimer - I found no such portal so I'm calling "dibs" on the name).
From software development standpoint it is a most basic app, that does the following:
The list is just an example, we can focus our tests on.
This is the place where you put the comprehensiveness of the testing effort. In our case the test approach might be as follows.
In a few sentences we were able to describe what we are going to test, and why we limit the testing efforts. On top of that let's move to the identification of the major testing goals.
We would consider the test deliverables as complete if all of the below occur:
- All CRUD operations on the User can be performed flawlessly
- The User authentication process is functional
- All user access levels are functional
- All CRUD operations on the Ad can be performed flawlessly
- The internal message system is functional
- The message system cooperates with external email tool
- The billing is done properly (i.e. no double billing occurs during the testing effort)
As you might remember from the last article - how to create a test plan, this is the place to describe the resources that will be used to test the designated app. We first describe the general info in bullets and then present the selected tool as well as other information on how and where does the testing activity take place.
To perform testing activities the requirements are as follows:
- A test automation tool
- Designated communication channels: email address and Slack channel plus access to Jira and GIT
- Implementing the testing tool to our CI/CD pipeline
- Separate server space and a test environment setup accordingly to the CD/CI pipeline so the latest released app version is in place
- Dummy data creation functionality in place, at least 10 users (2 admins and 8 clients) and at least 50 ads created
The decision was made to use a low-code or no-code test automation tool. As we have no tester per say in the team, this is the best decision from the business perspective. After thorough research we decided to choose BugBug as it has low entry requirements, is easily integrated with communication clients as well as CD/CI pipelines.
Providing the test environment allows a full understanding on what testing resource is needed to perform each part of testing services.
We have already described the testing scope, objective and the necessary tools. It is time to let the recipients know what human resources are we going to utilize and what would be the high-level approach to their work. Remember that it is not yet the time to define the schedule of testing. This chapter is also a good place to describe a high level situation of the app if it was not stated before. You can never foresee the changes in the team and what could be missed in the onboarding process.
In order to successfully complete the testing goals listed above, we need to consider our situation first. Given the agile approach to software delivery and MVP status we have decided that the testing efforts should be first and foremost iterative and highly automated. Each test milestone will cover the functionality provided in the latest development sprint.
The testing team will consist of the following:
- John Doe - test manager - major testing tasks and estimation
- Jane Doe - tester 1 - test execution, collecting reports for bugs encountered during the testing process
- Jeremy Doe - tester 2 - test execution and updating test scenarios
- Julia Doe - communication between the testing and the development team, assistant test project manager.
All of the above will be involved in testing for 20 hours per week.
Remember that the business and finances people also must approve this plan. This is why the example covers also information that helps with the estimation of the time required.
The core of the document. This is where you write the test scripts that will be executed. The software backlog is something that will support the test suites and cases for you. Given that we have chosen the iterative approach it will be relatively easy to pull the functionalities from the milestones identified in the software planning. The following also allows you to define any additional test milestones.
| ID | Test suite | Test case | Description |
|---|---|---|---|
| 1 | User creation | Proper data in user creation form | Insert proper and valid dummy data into the registration form. Check if the user was created correctly. |
| 2 | Invalid data in user creation form | Insert invalid dummy data into each field of the registration form. Check if the user is prompted about the mistake and if the user was created. | |
| 3 | Post creation behaviour | Check if the user is redirected to the profile page after successful creation | |
| 4 | User authentication | Proper data in the user login form | Insert proper and valid dummy data into the login form. Check if the user was authenticated correctly. |
| 5 | Invalid data in the user login form | Insert invalid dummy data into each field of the login form. Check if the user is prompted about the mistake and if the user was created. | |
| 6 | Check credentials for a new user. | Check if a new user without admin rights can access the admin panel page. |
This is just a brief, high level example to make it easier to create a test plan. Test cases and suites might not be put into a table for instance. The crucial part is - it has to reflect your needs and requirements. Maybe you need to place a column for test data, or just an "additional information" column will do just fine? Be creative in using this example.
This part of the test management has to consider the software project schedule as well. One thing you might reduce your effort with, is supplementing the table above with a "sprint number" column. That way you end up with a highly readable to do list. If you choose the more descriptive approach, try something like the following.
The testing will be performed on a similar schedule to the one the application is being designed. After each iteration is released to the relevant environment (at the end of each sprint), the test team will test the designated groups of features. As each of the people involved in the test phase is available part time, test items might require increased managerial attention. As of now there is little possibility to estimate the time required for each case to be conducted. This is mostly because the team is not yet onboarded to the chosen tool.
Remember that a good test plan foresees changes. Also note there is some flexibility in the schedule for each testing task, since you will deliver those on sprint basis. There is no need to plan the actions in high detail.
As we have already planned the whole testing process, the final touch would be to take care of the “what if..” scenarios. Yes, the final purpose of the test plan is to find actual bugs in your software. The final part of the document should then outline the course of action after a bug is found. Remember, that proper setting up automated processes here is an investment that will easily and quickly pay off. Imagine sending out a hundred emails weekly just to initiate the fixing process.
Thanks to multiple integration opportunities from the chosen tool we are able to notify the key people from both development and testing teams. To reduce unnecessary email communication, the reports on started and passed tests will be sent only via the designated Slack channel.
If a bug occurs, the following actions will be automatically undertaken:
- A message will be sent via the designated Slack channel
- An email will be sent to the Test manager and to the development teams’ PM
- A Jira ticket will be created with the description of the test case and error log
- A GIT branch will be created. It will be linked in the Jira ticket mentioned above
Such a flow will be efficient for the bug fixing process.
Do note that not every test management tool allows you to easily integrate such functionalities, so choose wisely. In the test plan template you will be able to download, you can also find a flow chart for defect reporting.
Here is one especially for you. After clicking the link below you can download sample test plan. If you are not the test manager, send it to someone responsible for providing the test documentation. It contains the cases described above but put into one easy to read document.
We are not yet tired of giving away gifts. A sample test plan template will enable you to document the procedures for your app and meet the delivery date. And at the end of the day, what does it do? After reading the last article you should already know. It saves you money! Successful delivery of test items might and will reduce the man hours spent on bug fixing. Our template is universal so it will cover every field of software testing.
If you feel that this article does not consist enough information on how to create a test plan on your own, you are right. We created a separate article that includes much more knowledge. Check it out here.
Happy (automated) testing!
Automate web app testing easier than ever. Without excessive costs. Faster than coding. Free forever.