Thursday, December 26, 2019

Robots slacking off

Dear readers,
this is very likely my last cartoon for 2019 and I am already looking forward to drawing and publishing the next ones in 2020.
14 cartoons in a year is not bad, considering the fact, I have hardly any time to settle back after work and after having helped kids for school.

For those who want to know, I have a quite consistent hit-count on my blog (1600 pageviews p. month). In my world this is a lot. Well, not enough to become famous but still a lot of reasons to continue drawing in 2020.  I wish you very XMAS (even though I am kind of late) and a happy New Year 2020.
Torsten J. Zelger

Sunday, December 8, 2019

False Positives

When developers start working on a new feature, they sometimes hard-code things with the intention to replace this part later with dynamic values. Sometimes, these snippets are forgotten, and you are testing features that work with hard-coded results. Success messages aren't excluded from this practice.

Simply said, never trust any success messages. If the program claims it worked, the program may be wrong. The opposite is also true.

The term "false positives" has its roots in medical testing. A false positive is an error in which a test result improperly indicates presence of a disease (the result is positive), when - in reality - it is not present, while a false negative is an error in which a test result improperly indicates no presence of the disease when in reality it is present. 
Yet another example:
Automated tests in NUNIT are declared with the "[Test]" attribute and in other programming languages there are similar terms in use to mark as method as test-method such as @Test, or other.
Anyhow, if a developer forgets to add the attribute, nothing bad happens. The compiler doens't care about it. The developer may have invested a lot of time developing the test case and then simply forget about this attribute. What happens is, the test never fails, because it gets never executed. 



Friday, November 29, 2019

Technical Debt not close-to-balance

I think it is normal in a project to accumulate technical debt somehow. You may have tough deadlines or other reasons to tend get things done more quickly than usual, probably with the mindset of getting it right later.

Other reasons for (quick) workarounds are new awarenesss (more experience) of how things work better under certain circumstances. The old approach was good for one particular problem, but not good enough for a general solution.

An increasing number of developers working on the same project may force the architect to enforce new coding guidelines or best practices for typical software development problems.

The use of embedded third party software may also trigger changes on your side when updates are delivered.

Technical debt should be avoided as much as possible and yes, there are scenarios where you are simply forced to live with technical debt. But, one should always be aware that, often, the time to improve old code won't be availble. Even if there will be such time, think about the risk of removing technical debt. Someone who works under pressure not only tends to seed ugly workarounds, but he is likely also adding sloppy unit tests (if he adds any at all). If that's the case, removing technical debts with refactored code adds new risks breaking functionality you won't know about until the customer reports them.

Saturday, November 23, 2019

Kind of mixed up

Fred: "Lucy, look I bought a pedal tractor for our kids".

Lucy: "No you didn't, you fool! "

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 Lambretta revival V-Special is an interesting alternative
to my beloved but seriously broken Vespa. I've read the Lambretta advertisement 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.

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 contains so much of the Sixties. There is also space for the helmet under the seat which is cool.
However, less joyful is the fact, that almost everything is made out of plastic. Would have been great if at least the wings could have been made out of solid metal. If you carry a passenger, the wing will be full of scratches shortly.
I understand, in order to save fuel, you need to consider weight, but a little less of elastic material is desirable.

While on the test ride, I realized the slightly oversized LCD monitor just below the small analog speedo. Unfortunately, the LCD is so big that you can hardly read your speed in the analog display which I think is kind of dangerous, because you spend too much time looking for the needle; time that may be needed elsewhere.

Overall it looks really nice. The designers did a great job keeping as much of the Sixties as possible. It didn't work out for the mounting actually and the plastic, unfortuantely, is a disappointement. I really hope they are going to change that soon.

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

Saturday, October 5, 2019

BETA Test at Green Galactica

One day the PL asked me to provide a checklist with the most important acceptance criteria and which served as checkpoints to enter the next phase of the project.The list was then extended with a few more items by the PL and PO themselves.When the date came close someone worked on the list and started to add an extra attribute for all checklist items to lessen certain acceptance criteria. When I realized the majority of the checklist items were reset to "NICE-TO-HAVE", I insisted to remove that new classification. Most of the items now classified as NICE-TO-HAVE were a clear NOGOs (look at the cartoon), but it seemed the editor started to realize one is not going to achieve a big set of these topics. My concern was that if something is labeled NICE-TO-HAVE the team wouldn't even start trying to work on the topic. What we then all agreed to made more sense: We kept the list as is and instead on D-DAY went through all topics together and discussed the current state of each acceptance criteria. We then decided whether or not we could still continue under this or that particular condition.

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.

[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
[3] Detection of Duplicate Defect Reports Using Natural Language Processing (Per Runeson & Magnus Alexandersson), IEEE 2007