Having been in the software testing business for a few years now, I’ve become accustomed to various types of testing: Acceptance Testing, Regression Testing, Exploratory Testing, Smoke Testing, etc. But in the last few weeks, I’ve been introduced to a type of testing I hadn’t thought of before: Pretesting.
On our team, we are working to switch some automatically delivered emails from an old system to a new system. When we first started testing, we were mainly focused on whether the emails in the new system were being delivered. It didn’t occur to us to look at the content of the new emails until later, and then we realized we had never really looked at the old emails. Moreover, because the emails contained a lot of detail, we found that we kept missing things: some extra text here, a missing date there. We discovered that the best way to prevent these mistakes was to start testing before the new feature was delivered, and thus, Pretesting was born.
Now whenever an email is about to be converted to the new system, we first test it in the old system. We take screenshots, and we document any needed configuration or unusual behavior. Then when the email is ready for the new system, it’s easy to go back and compare with what we had before. This is now a valuable tool in our testing arsenal, and we’ve used it in a number of other areas of our application.
When should you use Pretesting?
- when you are testing a feature you have never tested before
- when no one in your company seems to know how a feature works
- when you suspect that a feature is currently buggy
- when you are revamping an existing feature
- when you are testing a feature that has a lot of detail
Why should you Pretest?
How to Pretest:
1. Conduct exploratory testing on the old feature. Figure out what the Happy Path is.
2. Document how the Happy Path works and include any necessary configuration steps
3. Continue to test, exploring the boundaries and edge cases of the feature
4. Document any “gotchas” you may find- these are not bugs, but are instead areas of that feature that might not work as someone would expect
5. Log any bugs you find and discuss the with your team to determine whether they should be fixed with the new feature or left as is
6. Take screenshots of any complicated screens, such as emails, messages, or screens with a lot of text, images, or buttons. Save these screenshots in an easily accessible place such as a wiki page.
When the New Feature is Ready:
1. Run through the same Happy Path scenario with the new feature, and verify that it behaves the same way as the old feature
2. Test the boundaries and edge cases of the feature, and verify that it behaves in the same way as the old feature
3. Verify that any bugs the team has decided to fix have indeed been fixed
4. Compare the screenshots of the old feature with the screenshots of the new feature, and verify that they are the same (with the exceptions of anything the team agreed to change)
5. Do any additional testing needed, such as testing new functionality that the old feature didn’t have or verifying that the new feature integrates with other parts of the application
The power of Pretesting is that it helps you notice details you might otherwise miss in a new feature, and as a bonus, find existing bugs in the old feature. Moreover, testing the new feature will be easy, because you will have already created a test plan. Your work will help the developer do a better job, and your end users will appreciate it!