The image you might see above is a screen shot of what I saw after hitting the 12th page for the search results of "tester". I am not sure if you can reproduce that because I haven't investigated on it but I did plan to capture it to demonstrate:
"The test doesn't find the bug. A human finds the bug, and the test plays a role in helping the human find it."
Be it with the robust systems like Google Search Engine or with weak systems that we might be using, it is always a HUMAN who finds a bug. A lot of testers I know think of "test case" finding a bug.
There is a test case document that consists of 9856985956895869698569956985698459698 test cases and no tester executing it wouldn't find bugs by itself. There is a test case document with 3 documented tests and a tester takes the help of that to find bugs when he executes, observes the result and recognizes a bug.
A test case is an extension of a test idea. What matters to a tester is a test idea and not the test case. Skilled (exploratory testers ( humans ) use tons of ideas ( heuristics and oracles ) to find and recognize bugs. That's why they can find more bugs that matter than those running thousands of test cases over and over again.
Honestly, 99% of testers I have come across didn't say - "I read each test case each time I have to execute it after I have done it once. Also, I religiously follow what is written in the test case".
What happens when they deviate from the documented test case is, they are exploring and running different test. Maybe they don't like to call it that way because their management who pays wouldn't like to know that they are not executing the "test cases".
That's how customers are fooled by management saying "yes, we are running test cases" and yet benefited by the testing community by running more tests.
A test idea can be executed in hundreds of different ways. Check out the deep analysis made by James Bach and Michael Bolton on What Do Scripts Tell Us?
--
Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com
"The test doesn't find the bug. A human finds the bug, and the test plays a role in helping the human find it." --
10 comments:
Hi Pradeep,
Fantastic post once again!!!
But sadly, still in most of the companies people feel that a tester is nothing. Just a person who executes the written cases or scenarios. Only a handful of people truly appreciate the art of testing.
Today also people feel that its a developer who should be given all the credit & not the tester.
I wish to change this scenario sooner or later. Its very hurtful to hear that people here don't know Michael Bolton also.....!!!! Whenever I discuss yours, Michaels or Cem's blog people are like, "Uh!! Who are they?"
Its really a pitiful scenario & I really wish to change this one day.
@Roshni,
But sadly, still in most of the companies people feel that a tester is nothing. Just a person who executes the written cases or scenarios. Only a handful of people truly appreciate the art of testing.
The freedom struggle of India was started by a few people in different places and then more people got in to it and then it became a nation struggle. Testing as a human skilled activity is just like that, a few people like you and me have realized it and more people would join us.
I wish to change this scenario sooner or later. Its very hurtful to hear that people here don't know Michael Bolton also.....!!!! Whenever I discuss yours, Michaels or Cem's blog people are like, "Uh!! Who are they?"
A lot of testers might know Cem, Michael Bolton, James Bach or maybe even Pradeep and yet continue to do bad testing. A lot of them might not be able to recognize these names but are thriving to do a better testing each time.
Its important for people to learn to do better testing than merely knowing names of reputed credible testers.
However when you ( as a tester ) demonstrate something fantabulous in testing or maybe a little gimmick of better testing - they'd be interested to know how you get those ideas. Confidently say, "I get those ideas from my brain and tools like blogs and articles fro Cem, James, and Michael help me"
Demonstrate great testing to destroy bad testing - that's been my motto.
I'll definitely implement what you have said Pradeep.
Thanks a lot for your valuable commment.
Hi Pradeep,
Thanks for instigating the thoughts on testcases.
There is a huge difference in saying 'a testcase finding a bug' and 'a testcase helping a tester to find a bug'.
I have changed my post on
testcases after your bashing. :)
Jerison
@Jerrison,
Thanks for instigating the thoughts on testcases.
There is a huge difference in saying 'a testcase finding a bug' and 'a testcase helping a tester to find a bug'.
You have demonstrated a change in thought process as you learn. You have set a good example.
I have changed my post on
testcases after your bashing. :)
After the bug bash? ;-P
>>> A test case is an extension of a test idea.
Here is a rephrase. A test case is a possible (often vague) represenation of a test (an idea).
Michael Bolton once mentioned - A test is a reified entity (not real) but may be a test case is a real entity.
What is difference between test and test case in the context of a test design process (you can assume any missing context information, if any)
Why a test case is called so? (like a court case or murder case?)
What documentation has to do with test case? Is a documented Test called a test case.
Can a test case be considered as an example of a test?
>>>A lot of testers I know think of "test case" finding a bug.
This is so because, at the instance of bug discovery, tester and test are inseperable. Hence a tester can not distinguish between herself and test.
What is the point of proving the difference between Test and tester -
May be it is to drive home the point that it pays to rely on human brain of a tester rather than some documented test case written by others several years ago ...
>>.Check out the deep analysis made by James Bach and Michael Bolton on What Do Scripts Tell Us?
An important lesson that I learnt from this talk is about "how important is testing mission in test design". when the testcases are designed (prepared, documented, written !!!!) once and repeatedly used later (mostly in a different context and for a different mission) - you will have problems like mis-directed test effort, pesticide paradox and others.
Shrini
Hi Pradeep,
Yet another fantastic post from you! Thank You for this.
I completely agree with what you mentioned about exloring the product.
From my personal experience, these were the problems I faced:
1. The management more or less prefers to take up Exploratory testing after the Scripted testing is complete.
2. If at all, Exploratory testing is done and the results do not show much of a progress the first time it is experimented(say very few defects have been filed), then it is scrapped telling it is waste of time
3. Where is the time? We are already tight in schedule? is the counter question whenever I talk about exploratory testing.
How do I go about convincing my folks about it?
Appreciate your time.
A great article from you.
I agree with what roshni has said.I wrote a post on my blog as well
http://testobsessed.blogspot.com/2008/07/software-testingan-underrated-skill.html
Do checkout.
I really like your thought on tester finding a bug.
Jaanvi
@Parimala,
How do I go about convincing my folks about it?
One of the way that has worked for me is - to demonstrate the value of exploratory testing and educate my management about it.
@Parimala,
How do I go about convincing my folks about it?
I asked this same question to Pradeep & he told one of his mantras (as I like to call it), "demonstrate something fantabulous in testing or maybe a little gimmick of better testing - they'd be interested to know how you get those ideas."
Trust me I implemented this thing here in my organisation & now my colleagues jump to go through Pradeep's blog & then try to implement it in their own projects.
I am happy to see that finally we had a break through here. But still there's a long way to go.
Post a Comment