Presumption of innocence or Prove the defect.
Submitted by Ainars Galvans on Mon, 21/05/2007 - 11:49.
context-driven testing | metaphors | people issues
This is a simple hint to improve your credit score or how not do decrease it at least.
As a tester my job is to find something that does not work as expected. However whenever I find something I calm down my hunter’s joy and closely investigate the problem before reporting it. More over when something “does not work at all” I do not throw that fact “over the wall” to developers. That may or may not be their fault. Even if I do throw I pretend to ask for their help.
Presumption of correctness
Presumption of innocence states that no person shall be considered guilty until finally convicted by a court. In principle, the defense does not have to 'prove' anything. The prosecution has to prove breaking the law.
I hope the following metaphor will guide you in gaining better credibility. Whenever reporting a defect do you have a proof beyond a reasonable doubt that the piece of a code is incorrect? Could you convince the developer/manager?
Thus I do recommend whenever your tests fails or in any other way you observe something that does not completely much with what you expected do not assume the code to be wrong in the first place. It may be your mistake – mistyping test values, misinterpreting test case, misunderstanding expected results/requirements, wrong environment, errors in test drivers/database, etc.
The black hole of “It does not work at all”
The main indicator that you need apply presumption of innocence: application does not start at all; or the main feature is not working as intended even in happy-path. I’ve seen testers assuming that developer did something wrong and delivered crappy software to him. I don’t. I always believe developer has done at least some testing and the reason for not working is one of the following: different environment, issue in a build process, something that I assume to be happy path is actually different from developer’s happy path (for example my user name differ from password while developer have them equal).
Even if it is still code error, for example if reason why developer’s happy path do work is his wrong environment (e.g. does not much with customer’s environment as it include paths to local libraries, etc.) it is better to tell developer: “I can’t get that stuff to work” instead of “It does not work”. So little difference and so big at the same time. Let’s imagine yourself as a developer who have done quite reasonable unit testing and know it does work (at least in his environment/data). So when he see tester’s statement “it does no work” he is mad at a stupid tester in best case or in worst case thinks – well if all of my unit tests were no use to ensure that it work, then why should I write them. I’ll skip unit testing next time as testers anyway seems to be certain I do not do them anyway!
So my little recommendation
I do following: whenever something does not work at all I ask developer to show me his happy path tests and try to figure out what is the difference in my case so that it does not work. It could appear this is not a fatal bug, but only undocumented limitation... :) and this is not a little difference as perceived by project manager.
On the other hand if the happy path work, but some quite complicated case (requiring tester’s mind to imagine that case) does not – I am pretty sure developer simply missed that case and could do reasonably little work of collecting proofs.
As a tester my job is to find something that does not work as expected. However whenever I find something I calm down my hunter’s joy and closely investigate the problem before reporting it. More over when something “does not work at all” I do not throw that fact “over the wall” to developers. That may or may not be their fault. Even if I do throw I pretend to ask for their help.
Presumption of correctness
Presumption of innocence states that no person shall be considered guilty until finally convicted by a court. In principle, the defense does not have to 'prove' anything. The prosecution has to prove breaking the law.
I hope the following metaphor will guide you in gaining better credibility. Whenever reporting a defect do you have a proof beyond a reasonable doubt that the piece of a code is incorrect? Could you convince the developer/manager?
Thus I do recommend whenever your tests fails or in any other way you observe something that does not completely much with what you expected do not assume the code to be wrong in the first place. It may be your mistake – mistyping test values, misinterpreting test case, misunderstanding expected results/requirements, wrong environment, errors in test drivers/database, etc.
The black hole of “It does not work at all”
The main indicator that you need apply presumption of innocence: application does not start at all; or the main feature is not working as intended even in happy-path. I’ve seen testers assuming that developer did something wrong and delivered crappy software to him. I don’t. I always believe developer has done at least some testing and the reason for not working is one of the following: different environment, issue in a build process, something that I assume to be happy path is actually different from developer’s happy path (for example my user name differ from password while developer have them equal).
Even if it is still code error, for example if reason why developer’s happy path do work is his wrong environment (e.g. does not much with customer’s environment as it include paths to local libraries, etc.) it is better to tell developer: “I can’t get that stuff to work” instead of “It does not work”. So little difference and so big at the same time. Let’s imagine yourself as a developer who have done quite reasonable unit testing and know it does work (at least in his environment/data). So when he see tester’s statement “it does no work” he is mad at a stupid tester in best case or in worst case thinks – well if all of my unit tests were no use to ensure that it work, then why should I write them. I’ll skip unit testing next time as testers anyway seems to be certain I do not do them anyway!
So my little recommendation
I do following: whenever something does not work at all I ask developer to show me his happy path tests and try to figure out what is the difference in my case so that it does not work. It could appear this is not a fatal bug, but only undocumented limitation... :) and this is not a little difference as perceived by project manager.
On the other hand if the happy path work, but some quite complicated case (requiring tester’s mind to imagine that case) does not – I am pretty sure developer simply missed that case and could do reasonably little work of collecting proofs.