Reproducing Bugs

There is no force on earth that can stop a bug coming into existence. Software applications and systems are built by humans and that makes them prone to flaws. We simply cannot guarantee a 100% bug free software in any case whatsoever. Testers within their roles need to understand this delicate situation. As bugs are a threat to the value of the product and finding them before going into customer’s hand is something very challenging, it is also a pressure factor. During these time crunch situations, often time testers come across bugs which they cannot reproduce, but later on the same bug is reported by the client. For testers, this is something very irritating, but also to be noted, that this is the most common scenario that happens. Here is how testers can manage their activities to reproduce those bugs and prevent dissatisfaction happening at the client side.

Map the Application

Without map a traveler cannot move to her destination. Without map, people cannot return to the tracks of explorers, similarly with the absence of application map, a tester cannot move around the application. Start with the menus, then work the business flows. Distribute the map in component to component relationship. This way, you would know exactly where you are, where you are coming from, what’s the next access point. Mapping an application also help in gaining an overall domain awareness for any application. It is also a very healthy exercise for testers. It helps them learn about the application in a very organized and detailed fashion. Once a bug is identified, and it needs to be reproduced, the map helps the tester in pinpointing the exact position of interaction, and this makes things a lot easier.

Make notes

As a tester you need to be an expert in recording stuff, even the most trivial ones should not escape your observation, and eventually end up somewhere in your notepad. Using notebooks is very cost effective and keeps you on the edge of your seat while you are testing. To make notes effectively distribute your page in four sections, and as you move around the application, mark your findings as per the hierarchy you follow. Use different color pens to indicate Observation, Error, or Suggestions you are coming across. After a designated time stop your work, go through the notes you have made, and record them on issue tracker, or the tool you use to record observations. This helps you as a tester to reproduce complicated scenarios, as you will be noting down everything on the go. Remember, software testing is an open-ended investigation, and it requires the same traits and talents of a detective. Often time, you don’t even remember what you had put down in your notebook, but at the right time and place it reveals itself to you, and that’s where it pays off your hard work.

Record your test sessions

There are several screen capturing and recording tools available, and they are free of cost. To enhance your observations and organize your activities, record testing sessions into small time frames. The best way is to keep the duration to 30 minutes. Anything you miss will be recorded, and you can confidently track it later. Keep a library of your videos and screen captures, label them properly, and keep a backup.

Don’t be random

Software testing is a highly organized form of skill. Even though sometimes it feels as if it is not, is not the case. In order to test a system, if the tester’s approach is random in its pattern, then the bugs that tester find along the way, are most likely to disappear within these random patterns. Always remember the analogy of phase space; a system exist in a phase space, where the modules and functions are embedded within one and other. Testers need to explore this space with the intent to find important bugs within a certain timeline. Being random can be part of a grand bug hunting strategy, but once a tester come across a bug, the actions should become precise and organized, otherwise, this would only be treated as a hit and miss.

Get a second opinion

Suppose you come across a bug during testing, but when you track it back, you were not able to find it. This does not mean that it’s not there, it simply means that you must be missing some steps or you forgot to place the breadcrumbs properly. This is the time when you seek help from your fellow testers and developers. You can tell them what you observed and guide them about the data and system flow you followed. The brain works in mysterious ways, because you have been working on one problem continuously, your brain as entered the in-attentional blindness, therefore a fresh second pair of eyes and ears can see and hear more clearly, and they do.