Bug Hunting Tips

image

If you grew up in a rural area like I did, you probably once knew about the joys of lightning bug hunting on a warm summer’s evening. A master bug hunter could not just go outside and find the bugs. You needed the correct tools, the correct team, andthe correct plan of action. Personally, I loved catching lightning bugs, and had it down to a proven methodology.

When I was still new to firefly hunting, I would try to catch them with one hand, and transport them to another hand without squishing or losing the bugs. Of course, I lost more than I caught. The best methodology is to confirm a calm, rain-free summer’s evening required for fireflies, use a small light-weight net to catch the fireflies, have a friend hold the jar to retain the fireflies, and catch the bugs while they hover near a light source. After catching, it helps for the teammate to count the amount of bugs caught, and to ensure that all the bugs caught indeed light up. It also helps to repeat the process by switching roles, to ensure that all possible bugs are caught.

Somehow, it makes sense that I would grow up to be a systems analyst and tester; I know I sound more like a software test lead than a bug hunter! Software testing, at its core, is not very different from bug hunting. Both have a standard lifecycle, with constantly changing technologies and tools that can aid in the efficiency of the processes: i.e. nets and jars - test tracking tools; both must occur at a certain time – after design/development or after it gets dark. Of course, both styles of bug hunting work better with a team to perform multiple duties, and switch roles when possible.

Software testing is best performed when the Test Team is able to follow a Software Testing Life Cycle (STLC).  Each step can be expanded and customized, but if possible, each step should be executed for a successful STLC.

The industry standard tests for an STLC are:

  • Requirements/Design Review;
  • Test Planning;
  • Test Designing; 
  • Test Environment Setup; 
  • Test Execution; and
  • Test Reporting.

Note: It is imperative that the Test team is more than one person, and ideally has individuals from the requirements and design phases of the project as well.

While the requirements/design phase of a Bug Hunting expedition may require the hunters to check to make sure it is a calm summer’s evening and to confirm the necessary net, jar, & and team, it is also possible for the Bug Hunter to start in the middle of a Bug Hunting Life Cycle (BHLC), perhaps without knowing the weather or the have the ideal equipment, and still meet the desired outcomes.  While it is ideal for a Software Test Team to begin by confirming requirements as the standard STLC phases suggest, it is possible for the team to begin at a different phase, as well. This is often necessary when the client does not have requirements, or the design team is working off of a legacy system with no written requirements document.

Teams can use industry standard software-testing tools such as Qmetry, Test Rail, Zephyr for JIRA, qTest, Test Lodge, or many more tools, or can rely on simple spreadsheets with customized columns and rows to track requirements or customized test plans made for situations without a requirements document. It is important to note that, whenever a test cycle is in progress, it is important for other team members to test and repeat the steps for a more thorough test.  Developers should of course test each case before attempting to resolve it. We follow this process as a team at Function1 to ensure that each solution is tested, retested, and designed according to written requirements, or client needs if requirements do not exist. Following this methodology ensures that our solutions are bug-free and meet the needs of our clients.

As with Software Testing, repeating steps in Bug Hunting always resulted in a brighter jar of fireflies, but looking back, I definitely became a better software tester than a bug hunter. I would usually open the jar and let them go at the end of the adventure. This step should definitely be avoided in software testing!

Subscribe to Our Newsletter

Stay In Touch