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?
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".
Just to confirm: This is different from "Boundary Testing technique".
9 comments:
Of course it's worth trying and name is also suitable. I wish I could know it earlier. There was an issue where ENTIRE PAGE of 'Tea-time with Testers' was by mistake getting treated as FOCUS AREA. And hence regardless of what link you click....it was redirecting to Dec'13 issue :-). I wasted almost 1 hr thinking that something was wrong with browser/server catch...but it was small issue of 'focus area' :-).
Thanks for posting.
- Lalitkumar Bhamare
Yes, Good Test. In web application also I have often seen similar behavior with a difference that rather being whole button to be reactive only text/caption is accessible. So when you click on area outside the text but with in the button it was not responsive. I know this is a bug but not as serious as was with the mobile app issue.
But I think it can also be part of Perimeter test heuristic
I think this is very interesting because it is the type of testing we do not discuss much. Not understanding the limits of a focus area could provide unexpected problems for the user. It can also go back to what is the best design for usability and appearance. Understanding and testing around the perimeter of a focus item is a good test.
Good post! I have found this is often overlooked and sometimes difficult to convince developers that it is actually a defect. Most often, I run across this with checkboxes that extend to the end of the page to the right.
James Bach addresses a similar approach with his "galumphing" test technique where the tester randomly clicks a path to a button around the page while testing. In that case, he is looking beyond the object perimeters to empty areas of the screen.
An interesting variation I have used during accessibility testing is to use the same approach using right click. I have uncovered some hidden right click menus that were never cleaned up when previous screen objects were hidden instead of removed on the screen.
Hey, Interesting post! I call this type of test as the 'fat finger test' :) and I've found apps behaving oddly / sometime erratically even on tablets where one would expect it to be spaced appropriately, let alone the mobile phones!
Thanks for the post.
I have tested the similar one in my project.
I thought its a general one.
I dint knew:
Changing the state of the button - enabled/disabled
How to do this?
I think this is very interesting because it is the type of testing we do not discuss much. Not understanding the limits of a focus area could provide unexpected problems for the user. It can also go back to what is the best design for usability and appearance. Understanding and testing around the perimeter of a focus item is a good test.
Thanks for the information...!!!
Awesome tip for testers...Thanks...
Post a Comment