Sunday, October 13, 2019

How dare you, Lambretta?

Usually I am testing software, but today, I enjoyed a 15 minute test ride on a brand-new Lambretta and
I decided to add my personal results to my cartoon blog even though this blog is mainly for software testing.

My goal today was to check-out whether the great Lambretta revival edition it is an alternative
to my beloved but seriously broken Vespa. I've read the Lambretta advertisment in the news. I checked many pictures and it made me curious. The longer I googled the more excited I got, and I also checked the price which seemed reasonable to me, until the moment I saw it live.

The positive things I noted was the quiet motor and the firm road holding at the speed of 80km/h. Something I wasn't used to my current Vespa. Also the design of the new Lambretta is great and remembering these great ages of the Sixties, but wait...everything is made out of plastic now.
I understand that in order to save fuel, you need to consider weight, but ...the front, the fender, the wings, I mean everything? Considering that this scooter is celebrated as the big revival of Lambretta, I really had not expected to meet such a big collection of elastic material.

When I did my test ride, I noticed the oversized LCD monitor just below the analog speedo. While I think it is kind of weird to add an LCD monitor to a vintage-a-like scooter, there was something else that really worried me. The LCD is so big that you can hardly read your current speed in the analog display above the LCD. Having to search the needle while you are driving uses time, time that may be needed elsewhere.

Here is what I don't understand in these days....designers do a great job making products look great, developers do a hard job implementing the requirements and testers test the hell out of these products to make sure, the customer doesn't get disappointed. And then, you meet a potential client in the shop who realizes within minutes what she is presented by the sales guy looks like a two-bit plastic toy. Product Managers...we need to talk ;)

Tuesday, October 8, 2019

He just knew too much

THE DAILY BUG. "A software tester was found dead due to an overdose of drugs yesterday evening at his home in lower Manhattan, New York. His body was discovered before dawn on Sunday, October 5. He was a professional software tester and known for his strategies in spotting even hard to find bugs. An interviewed friend on site believes, he was murdered. "The tester was threatened several times by suspicious phone calls", he said. The police states they have found traces left by ugly critters at the crime scene. The police also stated, the main suspect was identified as Dendro Ponderosa, a modified name which has its roots in the Latin name Dendroctonus ponderosae, a mountain pine beetle and a remote relative of Dendro. The police published an appropriate mug shot of the suspect."
Reported by Formica Rufa

Sunday, June 9, 2019

Duplicate Bugs Arguing in JIRA

I guess, we all agree, duplicate bug reports may cause people to spend time working on avoidable tasks. But it isn't always easy to find out whether or not a bug report is a duplicate.

When a developer believes that a series of bug reports all have the same root cause, she tends to claim these bugs are all duplicates. 
The test engineer on the other hand would disagree and state “these are all different scenarios from an E2E perspective”. 

At the time of reporting an issue, we usually don’t know the root cause unless we dig deeper into understanding the anomaly. Even if a developer assures the bugs all have the same cause, it still makes no sense to mark these reports as redundant. One can never be sure the developer is right.  

What if one or more of these issues is still broken after the developer fixed one or the other? Isn’t it a good idea to re-test all the identified scenarios where that bug left his mark?

Michael Stahl [1] makes an interesting note when he states:
"Why would the same tester report the same issue twice? It just adds extra work for the tester, who for sure remembers the first report. Usually, a duplicate bug is reported when two testers identified the same problem and both reported it without first checking if it’s already in the system".

I personally believe that doing an upfront research in the bugtracking system doesn’t really help avoiding duplicates. The best experience I’ve made is to contact your colleagues directly rather than searching for bug descriptions which use different wordings. A screenshot could help setting the record straight, but searching for clarifying pictures is even harder. Better ask your colleagues directly “have you already seen that…”.If no, raise the issue, if yes clarify with them verbally whether that's the same issue and then enrich the existing bug report with additional data if you have.

Even if your employees raise duplicate bug reports, I consider it a reliable indication that these bugs are either easy to find or really annoying.

But what are you doing if your customers raise bug reports? You cannot expect a customer to first ask all other customers whether they have the same problem. A customer does not care about how many times the same bug was already reported. Some smart techies might "google" for a solution to their problems, but you can hardly avoid duplicate bug reports raised by customers. For example, according to Castelluccio [2], Mozilla receives hundreds of bug reports and feature requests from Firefox users every day. It is clear now that in such cases, tools are required which categorize bug reports based on similarities of other bug reports to save a developer's valuable time. 
 

Per Runeson [3] describes an approach using NLP to support the automatic identification of duplicates. Their conclusion: "Even though only 40% of the duplicates are found using this approach, it still means a substantial saving for a major development organization"

However, the best way to avoid duplicate bug reports is fixing any reported issue as soon as they are reported before another user raises yet another duplicate.

References:
[1] When Testers Should Consider a Bug a Duplicate (Michael Stahl), Sticky Minds, January 15, 2018
[2] Teaching machines to triage Firefox bugs (Marco Castelluccio), April 2019 at https://hacks.mozilla.org
[3] Detection of Duplicate Defect Reports Using Natural Language Processing (Per Runeson & Magnus Alexandersson), IEEE 2007