Software Testing is a field, full of false beliefs, myths and misconceptions. You can find many misconceptions about software testing and tester as a whole. These misconceptions are predominant even among testers too. But situation becomes more dangerous when other stakeholders like the management and the client also get infected by these misconceptions. That can land a tester in serious trouble. I have come across many such misconceptions in my career and will try to list out few of them:
1. Testers are ‘negative thinkers’ and they ‘complain’ a lot – I don’t know whether testers are negative or positive thinkers, but they are no doubt some of the best thinkers. If you run out of ideas at any point, try to consult a tester. Chances are more, that you will get some wonderful ideas from him. And about complaining a lot, testers don’t complain. Rather they introduce you to the reality! They offer evidence and show how things in the software don’t work!
2. Testers like to break software – Testers don’t find any pleasure to break things. Rather the software is already broken and the tester only finds it out. Testers don’t like breaking software, rather they like in dispersing illusions that the software works properly. Testers try to free the stakeholders of the project from false beliefs. Testers are the people who introduce you to the realities.
3. Testers act as guardian of Quality – Testers are not quality police. Quality is something which is built into software. Since, testers don’t build software, how can they assure quality of the software? Testers can only provide quality related information to the management. Testers are service providers not quality guardians. Moreover, Quality can not be assured by testing. As Cem Kaner says, “Whatever is QA – that is not testing”. So concentrate on the job which you are best doing at, i.e. testing. Leave the job of Quality Assurance to your management.
4. Exhaustive testing can make software Bug Free – Let me tell you, there is no such thing like exhaustive testing! Simply because, the definition of exhaustive can vary from context to context. Any way, nobody can make a software bug free; even if he tests it for his entire life! Not even God. A tester’s job is to show the possible ways in which the software doesn’t work. But there is no such way to guarantee bug free software. Or to tell that the software has been 'completely' tested!
Think of Microsoft, where the tester developer ratio is 1:1. Still we see Microsoft Products being shipped with numerous bugs, security holes, vulnerability issues etc. Think of NASA, where the tester developer ratio is a whooping 5:1. Still disasters like Columbia could happen. Testers can find bugs in the software, but can’t make it 100% bug free. This is the truth and we have to live with it.
5. Testers and developers should not be friends – This is the most dangerous misconception, prominent in software industry. Even, I have seen management encouraging such attitudes among the employees. But this may do more harm than good and result in a dangerous situation. Rather, testers can get some valuable project related information from their developers. If they are friendly, then they can approach for some wonderful test ideas from the developers. Even the testers can get some important clues that can help them in designing powerful test cases. Remember, bugs are introduced by the developers. So they are the best person to know the possible ways to find them. Got any clue! :)
Try to make yourself and your stakeholders free from these misconceptions.
Happy Testing …
What makes a good Software Test engineer?
ReplyDeleteA good test engineer has a 'test to break' attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail.
Source: http://www.softwareqatest.com
I agree the above answer that good tester will try to break the software so that in production it will not fail.
Hi Debasis!!
ReplyDeleteI have a question for you!!!
How "Quality cannot be assured by testing?"
To the best of my knowledge,
Testing is useful in finding bugs(in my view let's say as quality perspective bugs) and this automatically puts quality a step ahead by fixing those bugs. Though we are informers of the quality, the process (testing) is a shadower of Quality.
If iam wrong please correct me.....
@ NSMV (Lakshmi),
ReplyDeleteThis is an interesting question and I am glad that you asked it! To answer such a question, I had written an article few months back. I recommend you to go through it (along with the comments left on the article) and leave your comment on it if you still feel - "As Testers we can Assure the Quality of the Product under Test"!
You said... Testing is useful in finding bugs (in my view let's say as quality perspective bugs) and this automatically puts quality a step ahead by fixing those bugs.
This assumption of yours can fail because:
1. It is an inherent quality of software testing that it can show that bugs exist, but not that bugs don’t exist.
2. Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual. — BORIS BEIZER
This is called as "The Pesticide Paradox". In 1990, Boris Beizer described the ‘pesticide paradox’ phenomenon: The more you test software, the more immune it becomes to your tests. He asserted that software undergoing the same repetitive tests eventually builds up resistance to them, similar to the reaction of insects to pesticides: if you keep applying the same pesticide, the insects eventually build up resistance and the pesticide no longer works.
So just because testing can uncover bugs, it does not necessarily mean that testing can enhance the QUALITY. Quality is a multi-dimensional thing and is much more than testing. Take this: A video game is released to market after extensive testing and with *almost* no known-bugs in it. What if the users playing this game don't find it interesting enough to play? What if they find the game to be too boring and difficult to learn and comprehend? Would you still call it a QUALITY video game, just because it is quite robust in it's design and lacks any serious bugs in it?
-Debasis.
Yes, your 5 myths are certainly myths. I think another one would be "Testers are no longer needed with Agile development because developers test their code". We have found that although the developers may do unit testing and perhaps even more than unit testing, there is still a big need for end user black box testing. Additionally, QA personnel on an agile team tend to do requirement work in tying product management to development.
ReplyDeleteEven I agree to your view that the programmer and tester should be in good terms so that they can mutually exchange their views and there will be betterment in the product development rather than fighting between themselves and utilizing the program as a weapon.
ReplyDeleteInteresting and a thoughtful post.
ReplyDeleteThis a very good write and useful piece of information shared.
Thanks! a ton for sharing your experience.
Regards,
Software Testing Companies