Sunday, November 29, 2009

What makes a good Software tester?

Software Testers are known for their creativity but at the same time are known as sadistic who handles dull or repetitive work. They do share many qualities as developers, but there is important difference that groups them apart from developers.

The few qualities that define good Software testers from my point of views are:

1. Good to know programming.

This can be debated. As most would assume that testers can be staffed with people who have no technical or
programming knowledge. This is not recommended, even though this is common approach.

Here are my few reasons for this section.

Firstly, Software Testers are testing software’s. So without technical background, they can't have real insight
about the kinds of bugs in the applications and the likeliest place to explore them. As we all agree that testers
will never have enough time to completely test the applications, also they'll compromise with available resources and thoroughness. Therefore testers must optimize scare resources, which mean they should focus on where bugs could be likely found.

Secondly, Testing methods are tools and technology intensive. Testing tools as well as products under testing are all built using technical and programming knowledge. Therefore, testers could be in-capable of using most of the test techniques and will be restricted to ad-hoc techniques.

This doesn't mean that testers should have programming training or have worked as programmers, but understanding the logical techniques and experience will be the easiest way to meet the "know programming" requirements.

2. Know the software application.

This is another side of the knowledge coin. The ideal testers should have an insight into how users will interact and exploit the applications features, and also the kinds of errors users are most likely to make. In reality, it is not possible for testers to know both the applications under test and complete programming language, they should be a compromise between the application and the logical architecture.

For example, for testing demand generation software, testers should know how marketers would use the product to automate lead generation and calculate ROI or for online retail order software, testers should know how users could exploit the online security.

3. Practice Intelligence.

There are many researchers conducted to determine what would make ideal testers and the common conclusions made with these researches are that, there are no single bench marks to predict ideal testers. Good testers are also smart people; the single most important quality for ideal testers is raw intelligence.

4. Be Hyper-Sensitive to little things.

Good testers notice little things that others (including programmers) miss or ignore. Testers see symptoms, not just bugs. We know that a given bug can have many different symptoms, ranging from trivial to catastrophic. We know that the symptoms of a bug are in turn related in severity to the cause. Consequently, there is no such thing as a minor symptom-because a symptom isn't a bug. It is only after the symptom is fully explained that we have the right to say if the bug that caused that symptom is minor or major. Therefore, anything at all out of the ordinary is worth pursuing.

For example, the screen flickered this time, but not last time-this is a bug. The report generated is off by 0.01%-great bug. Good testers notice such little things and use them as an entree to finding a closely related set of inputs that will cause a catastrophic failure and therefore get the programmers' attention.

5. Be Tolerant for Chaos.

People react to chaos and uncertainty in different ways. Some cave in and give up while others try to create order out of chaos. If the tester waits for all issues to be fully resolved before starting test design or testing, he/ she won't get started until after the software has been shipped. Testers have to be flexible and be able to drop things when blocked and move on to another thing that's not blocked. Testers always have many unfinished tasks during SDLC. In this respect, good testers differ from programmers. The testers' world is inherently more chaotic than the programmers'.

6. Practice people Skills.

Here's another area in which testers and programmers can differ. You can be an effective programmer even if you are hostile and anti-social; that won't work for a tester. Testers can take a lot of abuse from outraged programmers. A sense of humor and a thick skin will help the testers to survive. Testers may have to be diplomatic when confronting a senior programmer with a fundamental goof. Diplomacy, tact and a ready smile, all works to the independent tester's advantage.

7. Tenacity.

An ability to reach compromises and consensus can be at the expense of tenacity. That's the other side of the
people skills. Being socially smart and diplomatic doesn't mean being indecisive or a limp rag that anyone can walk all over. The best testers are both-socially adept and tenacious where it matters. Good testers can't be
intimidated even by pulling his/her rank. They'll need high-level backing, of course, in order to sign-off the
quality software.

8. Be Organized.

I can't imagine a scatter-brained tester. There's just too much to keep track of to trust the memory. Good testers use files, data bases and all the other characters of an organized mind. They make up checklists to keep themselves on track. They recognize that they too can make mistakes, so they double-check their findings. They have the facts and figures to support their position. When they claim that there's a bug-believe it, because if the developers don't, the tester will flood them with well-organized, overwhelming evidence.

9. Be Skeptical.

That doesn't mean hostile, though. I mean skepticism in the sense that nothing is taken for granted and that all is fit to be questioned. Only tangible evidence in documents, specifications, code, and test results matter. While they may patiently listen to the reassuring, comfortable words from the programmers ("Trust me. I know where the bugs are."), and do it with a smile, they will ignore all such in-substantive assurances.

10. Be Self-Sufficient and Tough.

If testers need love, they don't expect to get it on the job. They can't be looking for the interaction between
them and programmers as a source of ego-gratification and/or nurturing. Their ego is gratified by finding bugs, with few misgivings about the pain (in the programmers) that such finding might engender. In this respect, they must practice very tough love.

11. Be Cunning.

Systematic test techniques such as syntax testing and automatic test generators have reduced the need for such cunning, but the need is still with us and undoubtedly always will be because it will never be possible to
systematize all aspects of testing. There will always be room for that offbeat kind of thinking that will lead to a
test case that exposes a really bad bug. But this can be taken to extremes and is certainly not a substitute for
the use of systematic test techniques. The cunning comes into play after all the automatically generated "sadistic" tests have been executed.

12. Be Technology hungry.

Good testers hate dull, repetitive work. They'll do it for a while if they have to, but not for long. The silliest
thing for a human to do, in their mind, is to pound on a keyboard when they're surrounded by computers. They have a clear notion of how error-prone manual testing is, and in order to improve the quality of their own work, they'll find ways to eliminate all such error-prone procedures.

I've yet to meet a tester who wasn't hungry for applicable technology. When asked why didn't they automate
such and such-the answer was never "I like to do it by hand." It was always one of the following:
(1) "I didn't know that it could be automated"
(2) "I didn't know that such tools existed"
(3) or worst of all, "Management wouldn't give me the time to learn how to use the tool."

13. Be Honest.

Testers are fundamentally honest and incorruptible. They'll compromise if they have to, but they'll righteously
agonize over it. This fundamental honesty extends to a brutally realistic understanding of their own limitations as a human being. They accept the idea that they are no better and no worse, and therefore no less error-prone than their programming counterparts. So they apply the same kind of self-assessment procedures that good programmers will. They'll do test inspections just like programmers do code inspections. The greatest possible crime in a tester's eye is to fake test results.


Search in this page

References: Some of the contents may have reference to various sources available on the web.
Logos, images and trademarks are the properties of their respective organizations.