Heisenberg Principle In Testing

I've found unexpectedly the Heisenberg principle in testing:

Software Testing as a Social Science by Cem Kaner, 2008

More Bugs, More Testers Mistakes

Tester makes more mistakes if developer makes more mistakes.
On this week I noticed that if I - a tester - check some functionality with a lot of bugs in it and ping-ponging these bugs to developer several times (some developers can't fix bugs with one version), then with another "fix" I am more likely to be critical on code, not on myself. That means that I am more likely to report every suspicious thing about that functionality, even if it is not a bug.

Testers mistakes in that case are mistakes, that developer can't fix in code: wrong settings, for example; or wrong data; or misinterpretation of documentation.

If developer produces relatively clean code, I assume that if I find suspicious behavior it more likely to be my mistake (because I know, that this developer makes few mistakes). Or, in another words, the cleaner code usually is - the higher probability that founded bug is caused by tester.

This kind of prejudice is not productive, so every time I try to "reset default settings" and don't think about developer, who implemented the task, but think only about code and implementation. I even preferred to check anonymous tasks (without developer's or analytic's name), but unfortunately I can't do it in JIRA.

The Pareto Principle

I can't tell that it is very useful principle, but it nice to know:
Roughly 80% of the effects come from 20% of the causes

In testing it usually means that 20% of the bugs cause 80% of the crashes. In my practice it actually works.

Good more detailed article: Understanding the Pareto Principle (The 80/20 Rule). Surely read the last paragraph "Concluding Thoughts". The important thing in this principle - it is an observation, not a law of nature.

Laws and Rules

Here are some well known laws and rules, that are really useful in my opinion in testing area. Noway they are the only ones or the most important or something like this - they are just some laws that I prefer to remmember about while I am working.



KISS Principle by Kelly Johnson
Keep It Simple, Stupid!

YAGNI Principle
You Ain't Gonna Need It

New Jersey Style by Richard P. Gabriel
Worse Is Better
There is a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability.

DRY Principle by Andy Hunt and Dave Thomas
Don't Repeat Yourself

Duck Test
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

I Know It When I See It by Potter Stewart

Murphy's Law by Edward Aloysius Murphy
Anything That Can Go Wrong, Will Go Wrong

Sturgeon's Law by Theodore Sturgeon
Nothing Is Always Absolutely So

Parkinson's Law by Cyril Northcote Parkinson
Work Expands So As To Fill The Time Available For Its Completion.
The amount of time which one has to perform a task is the amount of time it will take to complete the task.

90–9–1 Rule
1% of people create content, 9% edit or modify that content, and 90% view the content without contributing.

Pareto Principle by Vilfredo Pareto
80% of your complaints come from 20% of your customers.
80% of the effects come from 20% of the causes.


And at the end the great words of Joshua Bloch ("Effective Java programming"):

Learning the art of programming, like most other disciplines, consists of first learning the rules and then learning when to break them.