How Bug Hunting Turns Testers into Zombies?

It is widely agreed that testers’ job is in finding bugs. Supposedly, this means that upon completion of the testing process all the errors should be found. However, we all know this is impossible due to almost infinite number of user’s actions combinations, environment variables and input data.

This pointless crusade for all the possible errors puts on false targets and transforms testers into bug hunters. As a result, team is trying to find bugs in most incredible conditions of application using, forgetting that any user is capable of crashing the app, if making some effort to it.

What makes an app good for user?

However, in real life user is more concerned about features that do work than about defective ones. Among other things, the search for such errors takes a lot of time and resources, and moves away from the main goal - to make sure that your app performs all the functions required by the user. Just look at the number of known bugs in any popular products (OS, browser, and office suite) and you’ll understand, that user is completely into functionality.

Project managers and developers may have a significant impact on testing conception in company by asking irrelevant questions like:

“How many bugs have you found today? What do you mean none? But yesterday you found about 16!”

These questions will definitely give the tester a wrong impression about results of his work, and he may turn into plain zombie-like error detector.

So how to humanize your tester?

In fact, the human-like professional tester should completely understand the project goals, adhere to its priorities and deadlines, and stick to values of all process actors. Let’s consider the following example of total project’s misunderstanding. Tester reports any bugs with low priority for four or five first days of testing process, and only then he informs about critical error – hey guys, online store’s order system isn’t working! This is surely unacceptable. Software tester’s job is in the first place to identify and report the kicker concerning the most important functionality, as well as to request the correction of the defect for further testing.

Another misconception is rather a deviation from the standard, which is due to the very notion of "testing": reporting as an error of its actual result, for example, any interface bug. The tester should understand the nature of the error, trace query status in a browser and, as a result, bring to developer the problem heart, not just the interface consequence (e.g. broken filter). In a perfect world, the non-zombie tester should:

1. Understand the tested product platform;

2. Point out the error state number in bug report;

3. Look for additional details in Firebug;

4. Provide programmers with extensive information to save loads of time on further development.

Bug hunting is also dangerous because it blocks the key functionality control . As soon as the detecting errors chance is small enough, testers recede it into the background. Lack of understanding of the objectives and in-depth knowledge about the product leads to an increase in percentage of missed defects. And we know that even a small error in the most important functionality will be very expensive, despite the impressive list of known bugs that were found in the most unlikely circumstances. However, this list will be hardly useful to any user or customer, if the basic functionality is faulty.

So, to keep our testers smart and human, we:

• Focus on critical bugs, not chasing enormous quantity of unrealistic errors;
• Train them to get product’s priorities, not braaainz;
• Require to understand the platform of product and make a full report on original error.