As software testers we are constantly investigating how we can become better testers.
Often the path to becoming a better tester is seen as becoming a more technically proficient tester, particularly as in recent times the role has become more technical. Although the path to becoming a better tester may be reached through changing the way we think rather than a focus on technical skills alone.
One approach to changing the way we think about software testing is the study and use of Heuristics.
What are Heuristics?
Heuristics are simple, efficient, fallible guidelines, which help us solve problems and make decisions.
Disciplines such as Psychology, Marketing, and Behavioral Economics have long used Heuristics.
Heuristics are simply a “Rule of Thumb”, for example as a rule of thumb you should test boundary values. Heuristics are not based on fact but are based on experience and sound judgment, its comparable to an educated guess.
Testers should be encouraged to use their intuition and error guessing skills. Although such an approach alone comes with a personal bias and lacks the ability to utilize the past experience of others in our decision making.
Heuristics help reduce our personal bias and help direct our analysis and decision making. Thus heuristics helps make testers more productive and reliable.
Example Heuristics
To help clarify further, I have added 4 examples of Heuristics below.
Example 1: CRUD (Create, Read, delete and update)
CRUD is a very useful and intuitive Heuristic. CRUD can be improved when used with the heuristic such as zero, one and many dependents.
What happens when the system has no data?
What happens when we attempt to delete 2 items?
Example 2: Personas
We all have personal biases so why not develop testing personas.
Different users use the software in different ways, once we begin to think how these different personas use the software it can provide valuable insights to our test case design.
Power users will probably use all manner of shortcuts, impatient users will repeatedly hit the keyboard/mouse when a system response is slow.
Personas can also be an opportunity to ensure that we cover the accessibility testing.
Example 3: Nouns and VERBS
The Nouns and Verbs approach can be used as requirements analysis technique in the absence of requirements and documentation or can simply be used a test design technique.
- Identify the Nouns and Verbs in your system
- Randomly choose nouns and verbs(see Email Client Example Below)
- Create a table of your randomly chosen values, these values may not always make sense but challenge yourself to find a closely related test case
- An example test case would be can you forward a contact?
Email Client Example
Verbs: Create, Send, edit, forward, copy, delete and move
Nouns: emails, attachments, contacts, accounts, folders
Example 4: I’m still dancing testing on my own
Pair Programming and Mob Programming have long accepted within software development teams.
Software testing can benefit from the same approach, *Pair testing and a *Bug Bash enjoys the same benefits of pair Programming and Mob Programming.
Test Techniques
Early in our software testing careers, we tend to learn a number of key testing techniques.
In recent times more college courses are beginning to cover these but often people were introduced to these techniques through courses as the ISTQB foundation syllabus. (The inclusion of software testing as a module in computer science courses is worthy of a future blog).
I believe that Heuristics can improve these key test techniques.
Scenario 1: Single input parameter and Combining input parameters
Equivalence Partitioning/Boundary Values and Pairwise testing
For single input parameter testing, we tend to use Equivalence class and Boundary Values.
We tend to use pairwise testing as a combinatorial method for testing each pair of input parameters to a system.
We use these approaches as the most common bugs are triggered by either a single input parameter or an interaction between pairs of parameters. Bugs involving interactions between three or more parameters are both progressively less common
Heuristics that can supplement these techniques are as follows.
- Test every error message: Error handling code tends to be weaker than mainstream code. For equivalence classes test both inputs and outputs because error messages are just another output type
- Test at the boundaries: similar to error messages, boundaries are more likely to reveal issue
- Goldilocks: Similar to boundary value analysis, too big, too small and just right
- Violate Data Format Rules: Enter a wrong email address, an incorrect postcode
- Beginning, middle, and end: Vary position of element e.g. special character in middle of string, delete item from end of a list
Scenario 2: Testing Business Logic
Different combinations of inputs result in different actions and this can be more difficult to show using equivalence partitioning and boundary value analysis, which tend to be more focused on the user interface.
Decision tables and state transition testing are very useful for this scenario and these techniques are more focused on Business Logic. We typically use Decision table when analyzing conditions and actions, and State transition when analyzing the state of change.
In the past, I have found decision tables useful when testing financial systems/e-commerce website and state transition when testing sign-in/sign-out systems.
Heuristics that can supplement these techniques as follows.
- Never and Always: Similarly to the “Nouns and Verbs” approach can be used as requirements analysis technique in the absence of requirements and documentation or a test design technique. In this approach, you analyze things that the software should always do and never do.
- Follow the data: Perform a sequence of actions and observe its effect on the data
- Sequence: Change the order of steps and if possible do things in reverse order
- Run tests that are annoying to setup: Easy to run tests are more likely to be performed
Scenario 3 UI/UX Testing
UI/UX testing is vital to the overall success of a software project. Often testers will perform tasks such as Verify All Navigation and Check Usability Conditions.
Heuristics that can supplement these techniques are as follows.
- Interrupt: Find ways to interrupt e.g. cancel user import, log out or shut down in the middle of a transaction.
- Input methods: This is related to Personas, different users interact with the software in different ways. Some type, while others paste. Some will use the arrows on the Keyboard, while others use the mouse.
- Sorting: The two keys issues with sorting on the UI are Alpha vs numeric and page sorts
- Violate Uniqueness Constraint: Attempt to create user with an email address that’s already in use
Summary
Heuristics are simply rules of thumb which make skilled testers more productive and reliable.
Heuristics can improve your approach to test design and execution and the underlying test techniques.
Could Heuristics change the way you think about your testing and set you on the path to becoming a better tester?
More Testing Blogs
If you enjoyed this blog, maybe you would be interested in my other blogs?
The Role of Software Testing – how did we get here?
Guest Blog: Writing Test cases – The Devil is in the Detail
References
Test Heuristics Cheat Sheet
Elisabeth Hendrickson, James Lyndsay, and Dale Emery
Books
The two keys books I used for this blog are below. Explore It! is a fantastic book on exploitative testing. Lessons learned in software testing references Heuristics and in general, is one of the best reads on software testing.
Elisabeth Hendrickson
Cem Kaner, James Bach, Bret Pettichord
This is a personal blog. The opinions expressed here represent my own and not those of my current or previous employers.
Muito esclarecedor. Obrigada.