Not all our testing time is spent effectively.
Sometimes I find myself at the end of a testing day feeling I could have tested much better. Realising that my testing was not as “good” as it could have been if I’d done things a little differently.
After analyzing my own behavior, and also based on talks with hundreds of PractiTest customers, I tried to put together a list of the main reasons why many of us waste our testing time unnecessarily, hoping that we can correct these issues and do a better job in the future.
1. You don’t set a clear goal for your testing task
Every time you sit to test, you need to have a clear understanding of why you are spending your time doing this specific task.
Is it because you are testing a new feature? Are you verifying bugs? Are you running the last sanity-checkup before a release?
Understanding your goal (and defining your objectives) is the only way to make sure you are focusing your efforts correctly.
Still, many times I see testers who start testing quickly and without really understanding their objective. Either missing the goal of their tests completely or failing to cover part of the testing task they were supposed to.
Taking a minute or two to concretely define your goals, and to verify they are aligned with those of the project and the team, will save tons of wasted time and efforts.
2. You don’t understand the value of the feature for your End User
Testing is (mostly) not about verifying the save button actually saves the changes on the screen. This can be done a number of more effective ways!
One of the biggest objectives of our work is to verify the functionality we are testing (or the change being made) will provide the added value desired on the side of the End User. Or in other words, will the feature make our user happier!
(Side note, I love how in our last OnlineTestConference Gerry Owen clearly and accurately defined Quality as Customer Happiness!)
The only way to understand if the product will satisfy the needs of your end user is to understand what your end user wants to do with it.
The problem is that many testers do not invest the time to understand this point. Or even worse, they are removed from their users so that they cannot really judge whether the feature will help or maybe even harm their users.
It is true that you, as a tester, cannot know all your users, and you cannot replace your users as the people who will finally evaluate your product. But this is no excuse for not making an effort in order to learn more about them and to try to understand what functionality they need and what attributes of your product are more important or less important to them.
Not putting yourself in the shoes of your user(/s) may be a bigger mistake than many of us think.
3. You do not keep track of what you tested, your findings and the other ideas you got while testing.
I strongly believe that testing is both a science and an art.
A science, in the sense that you need to prepare yourself methodically to successfully run a test case. While at the same time it is an art, as you need to (almost instinctively) know how to adapt and change your testing based on actual stuff you find along the way.
This means that every good tester will be ready to modify their planned tests based on the findings of their testing. But the only way to do this responsibly is by preparing up front and keeping track of your testing and findings so that you can always come back and review what you found and why you made the decisions to shift away from your planned objectives along the way.
It is like walking a trail based on a map, but being ready to go off the path at any minute if you think there is something interesting hiding somewhere along the way less traveled.
How do you do this and still manage to achieve your goals? You need to be able to keep track of what you are planning to do, what you are doing, and the changes you are making to your plans.
Either achieve this by having a notebook handy and keeping a low-level and accurate log of your tests, or work with a system that allows you to plan your tests and also to modify them as you start working on your testing.
4. You do not consult existing information to get insights into your test
I really don’t understand people who say they consciously prefer not to see the previous test-runs or the bugs found in an area of the system in order to avoid any bias towards those areas during their current testing session.
Ladies and Gents, testing is not a double-blinded selection process, where you need to make sure you are “fair” to the product. Testing is a process to verify the product provides value and does not harm the work of your users.
And so, any help or inspiration you can get from previous runs and defects should be welcome in order to understand where we might have made mistakes in the past.
What’s more, your users will be less willing to understand a bug that is released again after being fixed in the previous version of the product, so previous bugs will automatically get a higher priority than “similar new” bugs.
With regards on how to make sure you don’t test the same things all the time, there are many techniques that will help you with this, and that will generate great ideas for new tests to be run on existing areas.
You can start by simply brainstorming with your peers, and if this is not enough you can go and check tests cases run on other areas, or look at bugs found in other products, etc.
The sources for inspiration are limitless nowadays when you can simply look for information on the Internet!
5. You do not do post-test reviews and feedback sessions with your peers
One of the things that have become clear to me with all my years testing, is that you can always get more ideas about what to test when you talk to people.
That is why whenever I think I am done running a test on a feature or product, I make sure to do a post-testing review session or walkthrough with a testing peer or even a developer on my team.
Simply by talking about what I did and found will help us to find additional ideas and areas worth reviewing and checking.
This is a simple trick that provides incredible value!
Testing is not Rocket Science, but it is not a trivial task either
I think that some people in our Industry see testing as a trivial operation that can be done by almost anyone.
It may be true that anyone can do some testing, but it is not trivial to do good testing or to provide a good level of coverage and visibility to the product you are testing. It requires planning, discipline and in many cases seeking feedback from others in your team.
If you have additional ideas that can help you stop wasting your testing time I will be happy to read about them in the comments section below.
Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.
Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.
With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.