Chances are, your AUT probably has buttons on the UI somewhere. If so, those buttons trigger actions. A common oversight is to not handle multiple actions being triggered at nearly the same time.
Testers and devs are familiar with standard UI controls. We know buttons don’t generally require double-clicks. However, many users don’t have this instinct. These users double-click everything, even buttons. Become one of them!
My AUT had a bug that actually allowed users to rapid-fire-click a generate invoice button, and get duplicate invoices. Ah…yikes.
Here is the bread and butter test:
Get your mouse over a button that triggers an action. Get your finger ready. Click that button multiple times as quickly as you can. Now go look in the DB, error logs, or wherever you need to look to determine if multiple actions where triggered inappropriately. No bug? Try it a few more times. Or try getting the focus on the button and using a rapid-fire [Enter] key.
Got any variations on this?
My opinions do not reflect those of my employer.
Subscribe to posts
RSS
Popular Posts
-
After attempting to use Microsoft Test Manager 2010 for an iteration, we quickly decided not to use it. Here is why. About 3 years ago we f...
-
Data warehouse (DW) testing is a far cry from functional testing. As testers, we need to let the team know if the DW dimension, fact, and b...
-
I recently read about 15 resumes for tester positions on my team. None of them told us anything about how well the candidate can test. Here...
-
Want your bug reports to be clear? Don’t tell us about the bug in the repro steps. If your bug reports include Repro Steps and Results se...
-
When someone walks up to your desk and asks, “How’s the testing going?”, a good answer depends on remembering to tell that person the right ...
Blog Archive
Labels
- Teamwork (86)
- bugs (81)
- process (66)
- software testing career (49)
- automation (45)
- writing tests (38)
- Personal Excellence (37)
- Managing Testing (33)
- questions (31)
- language (29)
- testing metaphor (23)
- Tools (19)
- STPCon (10)
- heuristics (10)
- Test Cases (9)
- test blogs (9)
- CAST (8)
- Presentations (8)
- Test This (8)
- metrics (8)
- Rapid Software Testing (7)
- Silliness (7)
- Data Warehouse Testing (6)
- Kanban (6)
- STARwest (6)
- Testing Conferences (6)
- Agile (4)
- Bug Report Attributes (4)
- Don't Test It (4)
- Stareast (4)
- documentation (4)
- Failure Story (3)
- Lightning Talks (3)
- Testing Related Ideas (3)
- You're A Tester (3)
- Performance Testing (2)
- Podcast (2)
- ATDD (1)
- BDD (1)
- HATDD (1)
- Meetups (1)
Who am I?
- Eric Jacobson
- Atlanta, Georgia, United States
- My typical day: get up, maybe hit the gym, drop my kids off at daycare, listen to a podcast or public radio, do not drink coffee (I kicked it), test software or help others test it, break for lunch and a Euro-board game, try to improve the way we test, walk the dog and kids, enjoy a meal with Melissa, an IPA, and a movie/TV show, look forward to a weekend of hanging out with my daughter Josie, son Haakon, and perhaps a woodworking or woodturning project.
My other passion is woodturning.
Test blogs I try to read
a post dedicated pour moi. i feel special. not really.
seems this would also be a good scenario to use automation to rapidly click on something for those testers whom aren't as quick on the trigger finger.
Yeah but then the dev will say "that's not fair, users can't do what automation can.". And they would have a good point.
In fact, when it comes to UI automation, great pains are taken by the test engineer to add random wait time, syncs, and other tricks to better simulate humans.
But I guess, to your point, a good tester could first determine the fastest humanly possible click time, and pass it into the automated test.
I wish someone would pay me to do this. It sounds much more fun than the testing I'm about to do when I click the "Publish Your Comment" button below. Oh, I'll see how fast I can click it. Hold on...
Yeah but then the dev will say "that's not fair, users can't do what automation can.". And they would have a good point.
In fact, when it comes to UI automation, great pains are taken by the test engineer to add random wait time, syncs, and other tricks to better simulate humans.
But I guess, to your point, a good tester could first determine the fastest humanly possible click time, and pass it into the automated test.
I wish someone would pay me to do this. It sounds much more fun than the testing I'm about to do when I click the "Publish Your Comment" button below. Oh, I'll see how fast I can click it. Hold on...
Yeah but then the dev will say "that's not fair, users can't do what automation can.". And they would have a good point.
In fact, when it comes to UI automation, great pains are taken by the test engineer to add random wait time, syncs, and other tricks to better simulate humans.
But I guess, to your point, a good tester could first determine the fastest humanly possible click time, and pass it into the automated test.
I wish someone would pay me to do this. It sounds much more fun than the testing I'm about to do when I click the "Publish Your Comment" button below. Oh, I'll see how fast I can click it. Hold on...
Yeah but then the dev will say "that's not fair, users can't do what automation can.". And they would have a good point.
In fact, when it comes to UI automation, great pains are taken by the test engineer to add random wait time, syncs, and other tricks to better simulate humans.
But I guess, to your point, a good tester could first determine the fastest humanly possible click time, and pass it into the automated test.
I wish someone would pay me to do this. It sounds much more fun than the testing I'm about to do when I click the "Publish Your Comment" button below. Oh, I'll see how fast I can click it. Hold on...
Yeah but then the dev will say "that's not fair, users can't do what automation can.". And they would have a good point.
In fact, when it comes to UI automation, great pains are taken by the test engineer to add random wait time, syncs, and other tricks to better simulate humans.
But I guess, to your point, a good tester could first determine the fastest humanly possible click time, and pass it into the automated test.
I wish someone would pay me to do this. It sounds much more fun than the testing I'm about to do when I click the "Publish Your Comment" button below. Oh, I'll see how fast I can click it. Hold on...
Yeah but then the dev will say "that's not fair, users can't do what automation can.". And they would have a good point.
In fact, when it comes to UI automation, great pains are taken by the test engineer to add random wait time, syncs, and other tricks to better simulate humans.
But I guess, to your point, a good tester could first determine the fastest humanly possible click time, and pass it into the automated test.
I wish someone would pay me to do this. It sounds much more fun than the testing I'm about to do when I click the "Publish Your Comment" button below. Oh, I'll see how fast I can click it. Hold on...
Awesome. Found a Blogger bug.
Blogger gave me this error:
"Conflicting edits
There was more than one attempt to edit this resource at the same time. This may have been because you double clicked on a link or a button or because someone else is also editing this blog or post."
However, they took my post 6 times.
Hah! Awesome!