When the problem is how we see the problem…

Many times I see how a tester “plays” with the system for hours without finding any relevant issues, and then how another tester or even a developer takes the same application area and “finds” a large number of critical and showstopper bugs that the first tester missed completely.

I used the words “plays” and “finds” on purpose since I think this is the main reason for these problems.

Testing is a contextual activity, meaning (in part) that how you define your testing objective will dictate as much as 90% of your results. In other words, if a tester only wants to run his scenarios and get over them quickly he will find only the issues that practically jump on top of him; but if the same tester is actively seeking bugs and does it based on the understanding of the application and its context he will be many times more effective and will find bugs that are not trivial or even apparent at first sight.

For me this falls under the category of testing professionalism, and even though this professionalism is perfected over time it is not only something you see in testers with many years of experience.

As part of my preparation for a testing task (regardless if it is a 15 min Sanity or a 90 min Exploratory Session) I make sure I understand what are my objectives and what I want to achieve.
For example, for a regression test to cover functional changes or bug fixes I will review not only what was changed but also why? If I am validating a new browser I will seek information on the Web from technology reviewers or previous testers that already had a chance to take it for a test-drive. Or if I am seeking to pinpoint some “unexplained instability” reported by another tester I will at the very least try to understand what was he doing and where was he working at the time.

Testing is not a walk in the park when you let your feet decide where they want to go, it is professional work and you need to let your mind do the navigating for you.

Based on each objective you set, you should approach the application differently and in a sense wear a different set of “testing glasses”. These glasses will dictated the way you see the application and what parts of it enter your “testing-context-framework”.

As a separate note, this is also one of the reasons a tester shouldn’t test if he is too tired or distracted, or why as a manager you should not give a testing task to someone who is not motivated to do it.  If a tester cannot concentrate and give 100% of himself to find the issues in the system, then most probably he will miss some bugs and the ones he misses might be the important ones.

About PractiTest

Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.

Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.

With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.

One Response to When the problem is how we see the problem…

  1. Rob Lambert October 6, 2009 at 10:52 am #

    Hi Joel,

    Nice article. Absolutely agree that motivation is the key driver for finding bugs. As is emotion.

    I’ve seen this too many times. Un-interested testers attempting to test applications with little to no success.


Leave a Reply