Hello, my name is Karin. I have been a member of the Tester Work community since 2020 and I also create insightful content for both beginners and experienced testers. I hope my article will shed new light on the bug identification process!
Finding bugs in software can be tricky. Unless, of course, you understand the anatomy of a bug.
Although many like to believe that bugs are random and that adding more testers to a project will yield better results, bugs are quite predictable, and often 5 testers will find more bugs than 200 other testers in the same software if they know where to look.
According to the Pareto principle, more commonly known as the 80/20 rule, 20% of bugs will cause 80% of the issues. The art of software testing is thus knowing where 20% of critical bugs are most likely to be found.
The easiest way to describe the anatomy of a bug is by comparing it to plumbing. There are a few key places where bugs usually manifest, as shown in the picture below.
- Integration points
The most obvious place to start looking for crucial bugs is by looking at integration points in the software where external software connects to the software under test. In plumbing, a leak is most likely to be found at the point where the pipes connect to the wall. Similarly, in software, bugs are most likely to occur at integration points or points where the application under test integrates or interfaces with external software.
For example, social logins prompt the user to authenticate themselves through Google or Facebook to use the application. This is an example of an external integration point connecting the application under test with an external piece of software. These areas should be tested thoroughly.
Look for any possible integrations to third-party software and spend more time in these areas by making sure everything works well.
- Bends
Another common area for blockages to occur in plumbing is where the pipes bend. Similarly, in software, whenever one workflow or use case changes direction unexpectedly into a different use case or workflow, errors are more likely to occur.
Most designers and developers focus on a few use cases, following a specific sequence. They expect people to follow this same sequence. In real life, however, people change their minds halfway through a transaction, get interrupted, or decide to look for something else. Often, they will follow a different user journey than the intended sequence of events.
The majority of bugs occur as a result of users doing things in a different order than what was anticipated. While testing, try to change the goal of the user mid-way through a transaction after you have completed the obvious sequence of events.
For example, maybe you’ve already started the check-out process when you decide to look for another item to add to your basket. Are your items still in your basket when you return? Are the new items added correctly? Have you only been charged once?
- Connections
Leaks are common in plumbing where two pipes connect to extend the length of a pipe. These connections are typically strengthened by an external cover to ensure the two connecting pipes stay together to reduce the risk of leakage.
In software, connections can be found where two different parts or functions interact. For example, Facebook has a lot of different functions, like the security settings, the friends, the chat, the feed, the marketplace, the search, the post creation, and many more.
Each of these functions is most probably designed and developed by different teams. Although they are part of the same application, chances are that there will more likely be bugs when using different functions in a sequence than only doing something within one function.
When testing software, try to identify some of the key functions and make sure that you spend more effort testing the connections between these functions than just the function alone. In real life, a user never only performs one action like searching for an item in a marketplace. Usually, they do something before (like login), and after, like check-out and maybe share it with their friends.
Think like a user and what the average person would do when they use the function under test. What would make sense to complete a workflow?
- Weak points
Finally, whenever there is a weak point in plumbing, like a crack in a pipe, it is more likely that these already weak spots will break again rather than a new place in the same pipe cracking. The same is true for software. If you have found one bug there is a high probability that there might be more bugs in the same area.
Spend more time testing around a new critical bug to find related bugs nearby. When you retest a bug previously reported, don’t just retest the steps reported, but add as many possible use cases around this bug as you can think of.
