Yesterday I watched an interesting discussion between a really good tester and a really good developer. I don’t want to spoil the fun by adding my opinion…yet. So what do you think? Should the tester log a new bug? Please use the voting control below this post.
User Story: As a scheduler user, I want to edit a field with the fewest steps possible so I can quickly perform frequent editing tasks on the schedule.
Implementation: if users double-click on a target they get a window with an editable field and a flashing cursor in the field.
Tester:
I was testing this, and it seems to work if you do a distinct double click. It’s really easy to triple click, though, and then the cursor isn’t in the field even though [the window] is in edit mode. My feeling is that the users will see this as ‘it works sometimes and not others’. Is there any way to block that third click from happening if we get a double click from the users in that field?
Dev:
Not really, you would have to intercept windows events, and in that case you’re just masking and promoting users to continue to practice bad habits. The [problem] in this case would be especially bad, because they would double click in the field, and it wouldn’t even enter into edit mode. If they accidentally triple click, they can just click in the field and continue, but at least the control would be in edit mode.
Tester:
I just have a feeling we’re going to have complaints on it. I hadn’t actually realized I’d triple clicked several times, it just kept popping up in edit mode, sometimes with a cursor in the field and sometimes without. I’d thought it was only partially fixed until I realized that’s what I was doing.
Dev:
I see what you’re saying and I guess it’s fine to log a bug, but what is the threshold, is a triple click based on your average speed of clicking, a slow user’s speed of clicking, should I wait 100 milliseconds, 300? It would change from user to user. Windows clearly defines a double click event based on system settings that a user can change based on their system and their own speed of clicking. If we start inventing a triple click behavior, then we take over functions designed to be handled by the operating system that could easily introduce many other bugs. Detecting such an event requires a lot of thought and code, and would at best be buggy and worse introduce even more inconsistent behavior. Just my opinion on it though.
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
if the spec is the reason such small problems exist, change the spec. instead of double clicking: single click, button, link, hover.
I know it sounds crazy, but I think a bug should be logged and here's why:
The tester has observed behavior that seems to disagree with the requirements. How would anyone know to rewrite the requirements unless the behavior (and dev's explanation) are recorded.
Secondly, just because this dev doesn't think that the bug is a bug, doesn't mean that down the road, this issue really crops up as a showstopper and another developer may have to take a crack at it. Having it recorded in the defect tracking system just gives him that much more of a headstart on what has already been researched and discussed.
My POV on defects is - when in doubt, write 'em up.
Certainly a bug report should be written!
The question about if a change should be made in response to the bug report is a team decision, not just a developer/tester decision.
Hi Eric,
Is there any way to block that third click from happening if we get a double click from the users in that field?
That's the major miscommunication tester made. Surprisingly, developer felt in that trap.
Now, what kind of bug you are talking about?
Design, functionality, or usability?
Thanks,
Albert
What an interesting discussion. I can honestly say that I don't remember the last time I triple-clicked without explicitly meaning to (e.g. – selecting a whole paragraph of text).
My interface choice is a mouse and I don’t know how easy it is to inadvertently triple-click with a trackpad or a touch screen. It’s difficult to make a decision about logging the bug without more information about the application, its target userbase and the hardware it runs on; my decision would be influenced by these factors.
With the assumption that your “really good tester” is really good, I’m going to side with her.
If she believes that triple–clicks are probable, then they are. It’s up to the triage team to determine if it is technologically feasible to capture the triple-click and if the benefits outweigh the disadvantages. Perhaps the underlining OS may be able to capture the triple-click event? Perhaps the application can determine the delay between the first and second click of a double click (from the user settings in the OS) and ignore a third click for the same duration? Perhaps there is a better way of editing the field? Perhaps this bugs should be tabled for the current release and re-visited for the next one?
My view of the test team is that it is there to provide an extra set of eyes to the application and communicate what it learns about the application to dev and management. The line between providing good data and unhelpful noise is sometimes a fine one. Discerning this line is a hallmark of a “really good tester”.
I voted to log the bug. And I will incorporate triple-clicking actions into my tests.
The tester should ask for a new feature, since this is clearly not a bug.
To clarify this statement: The [problem] in this case would be especially bad, because they would double click in the field, and it wouldn’t even enter into edit mode.
The original bug was double clicking did not enter the control into edit mode AT ALL. This was obviously fixed. I don't have an issue with logging bugs I don't agree with, but at some point user error is user error, if we go through any product and start doing stuff far outside the normal use case, I'm sure we could uncover a few hundred bugs to clog up our bug queues and divert work from more important issues. This bug means the user now has to click one more time on the field they want to edit, because of their improper click; big deal. Depth testing is very important, but at some point you have to move on. I remember a bug from Eric at one point where he had to attach a vice grip to his mouse and the desk with the cursor over a certain point, and automate 300 clicks per micro second to cause a bug, THAT WAS WRITTEN UP!! If a user does that, then I have no sympathy for them.
The tester needs to log the bug so you have a record of the issue at the very least. Now whether or not DEV fixes or should fix the 'bug' remains to be decided. I don't think it is for DEV or TEST to decide whether the issue warrants a fix. TEST should report ALL issues. MGMNT should make decision. DEV should act on those decisions.
I agree with Scott. The issue needs to be logged, but it's not really up to the tester or dev to determine where it falls in the priority schedule.
That being said, I don't think this is a "bug". As the dev pointed out, a double-click is a specific action, and the implementation clearly supports double-clicking. Instead, the issue is one that should be logged as an Enhancement and analyzed during the UAT phase.
I'd log it as an issue. It is an unanticipated behavior, one that a user, just like the tester, may not realize they are doing it. The problem is what can you do about it?
That may depend on the system. The other problem is whether it is a fix that should happen? The Why question keeps ruminating in my mind. Why do you need to do a triple click? Why are you doing the triple click?
I worked in Tech Support for a little over a year, and there was this one guy who had this problem. His computer would crash inexplicably. We expected he had some kind of virus or malware, but he swore it always happened when he was in our software.
He said when it happened our program would not fill up the screen like they used to. We thought it was a redrawing error or a mistake in the registry settings for the window, but we tried all manner of things and couldn't fix it.
I sat in on this call once, trying to figure out what was wrong, and finally it took remoting into his computer the answer became plainly obvious. This gentleman, bless his heart, was working on something at the bottom of the window, and somehow resized his windows task bar so it covered the entire screen.
Once we realized what the real behavior was, and that it wasn't a problem with our software, but a feature in the system it ran on, we knew from then on to watch for it. So I'd log this as an issue, that if not fixed should be come a FAQ item somewhere even if just for those who will support the system, so that in the advent someone does reproduce this behavior, they'll know why.
So another question the Tester must ask in this case is this a bug with our product? Or is it the result of the system? That's something we need to remember, and it may not always be obvious.
Yes, The tester should log the bug.
It depends on the PM to decide that the bug should be / can be fixed or not. In your example after the QA posts the bug, the build can be shipped with this issue marked as a known issue.
A bug is not only fixed by writing code. There are various other methods. e.g. the developer can include this scenario in the help file, so that if any users come across this issue, they atleast have some help and support and dont get negative about the application.
Thanks,
RP
Why should we log a bug?
Because there is a possible usability issue that needs further investigation. discussing that in a meeting will not help to decide, but experimenting with the GUI will help to understand wether we have a problem here or not.
Experimenting with other popolar software behaviour in such case could give us a good oracle if this behaviour is acceptable by users or not.
In case that editing this field worth LOT of money (Is this a payment transaction field of high traffic commercial site...?), I would suggest a more proffesional usability survey
A hard choice, a good question!!
I personally don't think that is a valid bug, because it is hard for normal users to make a triple-click, 99.9% computor users know how to make a double-click correctly. Anyway, even that happened once to some users, they should easily know how to resolve it without any actual impacts on using, just click again on edit field.
So why not pay limited efforts on major issues (that would prevent users from using, data losing, can't input, crash, etc)?
Any comments?