How about "The Yellow Face" Heuristic?

I was reading the book 'The Memoirs of Sherlock Holmes' and found this interesting case called - The Yellow Face. This is a good read. Sherlock is asked to help a man who feels that there is a secret between him and his wife. Sherlock suspects that its the lady's first husband who has come to the cottage and blackmailing the lady, along with another lady.

Only when they reach the cottage, Sherlock and the man realize that it is not the first husband but the child who was unwell and has now recovered. So, Sherlock fails to solve the case or to be fair, his assumptions and inferences about the case is false.

After reading this story, I realized that investigation is a key skill in software testing as well. Think about how we listen to the facts, lay our assumptions, build a story, conduct experiments and prove our theories or learn from it. Sometimes we go ahead and without any experiments, conclude that our theory is correct. Just before the story ended, Sherlock tells Watson 

'If it should ever strike you that I am getting a little overconfident in my powers, or giving less pains to a case than it deserves, kindly whisper 'Norbury' in my ear, and I shall be infinitely obliged to you.'

Just when I read those words, I felt that it can be turned into a heuristic - "The Yellow Face" heuristic. A heuristic which warns the testers against complacency. Against believing a theory without enough investigation, without enough critical thinking. 

Imagine in a project when someone is building assumptions after assumptions, just tell them - Beware of the yellow face heuristic

Leia Mais…

The Perimeter Test: A new test idea?

We have bug bashes in our company. In every release, the tester invites other testers to test his/her feature. Fresh eyes, different experience usually helps in bringing new test ideas and bugs to the forefront. I usually participate in such bug bashes as it exposes me to different features and test ideas. It is a good opportunity to practice testing and a good break from regular testing too.

In one such testing session, I found a bug where the button was tapped even though I did not tap the button. On further investigation, I realized that the focus of the button was much more than the button area. Let me highlight the issue with the help of the following image.

On the left image, we have a problem. The button's perimeter is displayed by red color.
But when the user taps or clicks anywhere within the green rectangle, the button is still clicked.

On the right image, the focus of the button is limited to the area highlighted by red color. On tapping or clicking outside the red area, the button is not activated.

How do we usually test such buttons?

• Clicking on the button
• Changing the state of the button - enabled/disabled
• Test the default state of the button
• Combining the button action with other actions

What am I proposing?

I want to include a test to click around the button to check if the focus of the button is restricted to the button area or extends outside the button area. According to me, the name for the test idea: "The Perimeter Test".  

Why this bug is important:

a. The user might not know that the click outside the button behaves similar to click on the button.

b. It would be confusing if there is little space between adjacent buttons. The user will not know which button was clicked.

c. The trust on the application's behavior is reduced as the user is not sure of what to expect.

I would like to highlight the Perimeter Test's importance on mobile devices and areas where multiple buttons are placed close by. Try 'Inspect element' on the button and discover the area quickly. Also, the Perimeter Test might not take more time. A quick test to highlight an important bug.

I am happy to give the test idea a name and hope to come up with more such test ideas.

What do you think about 'The Perimeter Test'?

Just to confirm: This is different from "Boundary Testing technique".

Leia Mais…