Intuitive Repulsion

On Thursday January 17 2007 my colleague Shoukath presented me a puzzle. It is "--/- = --/- = --/-" where - is a number between 1 and 9 and no number must be repeated twice. From the first look itself I got an intuition that the dividends of all the numbers must be multiples of nine and divisors of all the numbers must be factors of nine. I worked that way and I solved the puzzle quickly.

The answer is 81/9 = 54/6 = 27/3. If u asked me about the cause of that intuition my answer will be "I don't know". Even then I followed it and solved the puzzle easily.

My question is "Is it a good idea to follow such instincts?"

In the book "Blink: The Power of Thinking Without Thinking" author Malcolm Gladwell call such a process as "Intuitive Repulsion". The book is all about snap judgments and the contexts in which it proved useful. The author states that "The decisions made very quickly (snap judgments) are every bit as good as decisions made cautiously and deliberately".

I am not sure about weather we should follow such instincts especially when it comes to testing. If following such instincts ends in uncovering bugs then it proves to be really useful. Because delivering (quality) products in time is the major concerns of all management.

And I believe that concept of "Blink" is a two sided blade. It can prove to be useful in times as well as it can mess up your whole testing activity because we are making decision based on little information. So be careful while making decision on weather to follow or not to follow your instincts.

Post Script:
In the post "Quick Oracle: Blink Testing" James Bach describes about "Blink Testing". It is a testing technique that he found helpful. Blink testing is not about snap decisions but about recognizing patterns automatically. He has specified lot of examples where Blink testing will fit. I too tried "Blink Testing" for checking log files, for testing and comparing web pages (I was working on a project for migrating web pages from .Net to J2EE Technologies). And Blink testing really proved useful. Thank you James.

Updated On 02-Feb-2007

I am updating this for sharing some interesting information about "Blink Testing". Pradeep Soundararajan shared this information with me by leaving a comment on my blog. The information is "It was Michael Bolton who coined the term - Blink Testing!". Thank you Pradeep, for sharing such information's.

Here is one more interesting link "Blink . . . or You'll Miss It". It is an article on sticky minds posted by Michael Bolton.

Thanks & Regards

Nishanth Balachandran

Who Is Responsible For Poor Quality Of Software?

The answer is obvious "Testers". Let them be in any form or in any name like QA, QC, or Tester. They are responsible for poor quality of software. Do you agree with this? I hope you don't agree because the answer is wrong. There may be chances that testers are responsible for poor quality of software but not always. "Obvious answers may not always be the right answer".

Beginning Note:

All the statements and claims made by me in this post are my learning from my experience. I have tried my best to make it informative, meaningful and truthful. I have not intended to hurt anyone by the statements in this post.

My Answer:

I believe that every one associated with the project who did injustice to their work is responsible for poor quality of software. It may be the guys of top management who believe 10 women can give birth to a baby in 1 month. It may be programmers who are aware of the existence of a bug but still they are waiting for a tester to find that bug for fixing it. It may be Testers who just merely tested the product and didn't test with passion.

Top Management:
The roles and responsibilities of top management in a project are very huge. They are responsible for recruiting developers and testers, making schedules and so on. While creating a schedule if any doubt about the completion of project with in timeline arises in their mind then they need to rethink about it and reschedule it. They also need to make sure that they recruited right people as well as right amount of people for the project.

Developers:
I have great respect for developers. There are developers who really work hard and work with passion so that they can develop a quality product. There are developers who respect testers and fix the bugs with real interest. But there also some developers who are aware of the existence of a bug but still they are waiting for a tester to find that bug for fixing it.

Testers:
Before writing anything about testers I recommend you to read Pradeep Soundararajan’s post "Being a tester V/s Working as a tester". In that article Pradeep shares his learning about two kinds of testers.
a) One who is a tester.
b) One who works as a tester.

I fully agree with his learning. And I am simplifying it again.
a) Good Testers
b) Bad Testers
Good testers are testers who have passion and skill for testing.
Bad testers are testers they lack passion for testing and they are on to testing because they want a job.

If a tester from the second category is testing the software then there is lot of chances to miss bugs. And the result may be poor quality of software. In such cases testers are responsible.

Addendum:
I have heard people blaming and cursing Testers for poor quality of software. For such people I have a request "Before cursing or blaming a tester for poor quality of software please think about other factors also”. Because it is not always true that testers are responsible for poor quality of software.

Thanks & Regards
Nishanth Balachandran.