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?

The more one learns about the inner workings of an AUT, the more one may get distracted from logging important bugs.

I saw this happen last week with a fellow teammate. She discovered a search criteria control that didn’t allow the user to search by certain values (e.g., they could search by A, B, D, but not C). Instead of logging a bug, she explained to me why it didn’t work. She was thrilled with her knowledge of countless dev discussions trying to fix the data structure beneath said search control. It was more exciting for her to explain the complex data than to worry about the little users who would not be able to search per their expectations. It was like she was suddenly on the side of the developers…and the users would never understand the complex challenges of making software work. “It’s not a bug, nobody can figure out how to deal with the complex data”.

Huh?

Dumb testers don’t have this problem. If it doesn’t follow the spec, they log it. And that’s the good thing about dumb testers. Be careful with your knowledge.

Alex and Joe,

I agree with both your comments to my last post.

Joe blames the dev…

“- No bug report- [dev] corrected it on their own”

Obviously devs catch defects in their code (logic errors, missed specs, inefficiencies). If devs find and resolve defects in previously released code, should a bug be logged? On one hand, if the dev corrects it before anyone else catches it, why should the dev have to tell anyone? If a tree falls in the forest and nobody is around, does it make a sound? On the other hand, we can’t assume an unnoticed defect in the field, means said defect’s resolution will also be unnoticed. Thus, IMO it’s best for devs to let the team know about all changes. Typical ways to do this:

• Dev logs bug


• Dev tells tester to log bug


• Dev logs a work item representing work they did (e.g., refactored code for FeatureA). The work item should be visible to the team. The dev gets credit for their wonderful coding, and the tester gets the tap on the shoulder to attempt some testing.

Alex blames the tester…

“That test should have failed a long time ago.”

In this case, the feature did not match its spec. You're damn right, the tester should have caught this! The tester should thank their dev for doing the testers job. (Unfortunately, if the tester relied on the spec, we would be right back where we started.)

So a third member must also take the blame; the spec author (e.g., Business Analyst), who did not capture the true business need of the feature. However, we can’t put all the blame on them. “The requirements sucked!” …this is a tired argument, one that I decided never to waste my time with. Anyone who disagrees probably has not attempted to write requirements.

The next time you feel compelled to point the finger at a teammate, don’t. Responsibilities blur across the software development trades and the whole team can share success or failure.

(sorry, this post is a little dull. I’ll try for something juicier next week)

My team just released a new build to prod that included a freebie from a dev. I say "freebie" because the dev noticed code not complying to a requirement and corrected it on their own. There was no bug logged.

It turns out, our users preferred the feature prior to the dev's fix. We are now in the process of rushing through a “showstopper” production patch to insert the previous code back into prod for business critical reasons.

What went wrong?