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?
Pretesting will save you the headache of trying to remember how something "used to work" or "used to look". If customers will notice the change you are about to make, it's good to make note of how extensive the change will be. If there are bugs in the existing feature, it would be helpful to know that before the development work starts, because the developer could make those bug fixes while in the code. Pretesting is also helpful for documenting how the feature works, so you can share those details with others who might be working on or testing the feature.
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!
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!
No comments:
Post a Comment