A heuristic is a shortcut or go-to models that allows people to solve problems and make decisions more effectively. These strategies shorten the time to make decisions and allow people to function without stopping to think about their next course of action. Doesn’t it sound good? In testing it’s important to shorten the amount of time that it takes to think when testing but we must be mindful of the cognitive biases that this entails.
Why do we use heuristics?
In order to cope with the amount of information we encounter and speed up the decision making process, the brain relies on these mental strategies to simplify things so we don’t have to spend endless amounts of time analysing every single detail.
In every single day, we are faced with thousands of decisions. In my case, the moment I wake up, I think “What should I have for breakfast?”, “What should I wear for work today?”, “Am I going to the gym later?” - The list is endless. The use of heuristics allows us to make such decisions with relative ease without a great deal of agonising.
Imagine you go to a new Chinese Restaurant, suddenly you are faced with a new menu but some items are familar to you. You quickly realise that ordering new food might not be good and you’re not willing to tell the waiter that the food is not what you expected, so instead, you simply go for what you know. In my case, the Sweet and Sour Beef is never a bad shout. Your heuristics allow you to think through the possible outcomes quickly and arrive at a solution that will work for your problem.
My test heuristics
Understand your mission - The whole team must be on the same page and understand the mission at hand. Most of the time, when we do something we have a goal in mind. You go to the gym, why? To get more physically fit. You go to the grocery store? To buy some food. The same goes for testing, you have to understand why you are testing.
When you are testing something, you know what the purpose of what your testing is. Imagine a release that will improve the speed of the platform as the clients have been complaining about the performance of a certain part of the system being used. Here is a basic idea on how I would think about this:
- This certain part of the system is not performing as fast as the client expects it to happen
- The problem with this is that the user may be getting the functionality that they want but they may find something better in the market and stop using our platform
- The loss of the client will not be good for business and may lead to job losses
Find Importants Problem Fast - Testing should be optimised to find important problems fast, rather than attempting to find all problems with equal urgency. For example, you have a platform that requires you a whole week of manual testing, do you test everything part by part? No - it is smarter to test the most important functionality.
When you find an issue, it will be time consuming. They are most likely to find new problem. Therefore, finding most important problems as soon as possible will give the team chance to better estimate the project and ensure higher quality release.
Maximise Diversity - When evaluating the test strategy should be diverse in techniques and perspectives. How you evaluate what you’re testing should take into account different dimensions of functional, data, and performance coverage. No one way view of techniques will reveal all the problems in software. Diversification minimises the risk that the strategy will be blind to certain kinds of problems.
Imagine you need to do a system test and you have a list of 200 items in a list. Would you consider testing these 200 items in the list? It would be ‘better’ to select one from the list and test other parts of the system than dedicate time to testing the whole list and not test other parts of the system.
Consider your stakeholders - Before, during, and after testing, collaboration should be one of the main points. This will be with your product manager, test manager, developers, customer team, marketing, sales, and many more. Whenever possible, the tester should collaborate with users in order to better understand what they are testing.
Other teams and stakeholders will have information about the product about pain points, bugs, problems and many more. Their perspective will help the tester to get a more complete view and make better analysis of what they are testing.
Minimise text - When writing test cases, avoid long winded and unnecessary text. Do not state the obvious, do not be too detailed as no one will read for too long.
Any text that is too long will reduce the likelihood that it will be read. Readers will assume that they already know what they are testing. Google’s Larry Page says that his colleagues know that sending him anything longer than a tweet increases the likelihood of him not reading it. If the previous CEO of Google says this is the case says so, then we should follow stead.
Instant Feedback - The feedback loop of the development team should be as tight as possible. When testing, feedback and bugs should be reported to the programmers as soon as possible.
When we find a bug, it may take time for it to be fixed and what you find may halt your testing, so give feedback as soon as possible as to not waste anyone’s time. This is extremely important to maximise the effectiveness and efficiency of the team.
Review and update documentation - Once you have completed the test cycle, you might have found a bug that was not included in your test cases. Add it to the documentation. The documentation you have written should be read by someone else as documentation should be understood by everyone.
When we are writing things, we can be somewhat lazy on our writing so that only the writer can understand this. You must think of your company, what if you become ill the next day and your team do not understand your documentation - You would not want a call when you are in bed with a fever.Reviewing the documentation will reveal blind spots in test design and team learning on best test practices.
A heuristic is a shortcut or go-to models that allows people to solve problems and make decisions more effectively.
- Understand your mission - Why are you doing what you’re doing? What will testing this specific item do to the system and how does it affect the users?
- Find Important Problems Fast - Critical functionality is working? As part of testing layers, the main functionality of the system should be working.
- Maximise Diversity - Diversify testing viewpoints. Tunnel vision to one view point will make sure that you will release with obvious bugs.
- Consider your stakeholders - How will this release affect stakeholders? What information do you need to understand how the program to be tested will affect them?
- Instant Feedback - Shorten the feedback loop on test findings so the decision makers can make decisions on the progress of the project
- Review and Update Documentation - Has your documentation been reviewed by someone else and did they understand your writing? Is your testing documentation up-to-date with the the addition of latest features and amendment of current features?