Nightmare Acceptance Test

 

In the need of a Neuralyzer

...

Birds love BUGS

Here are the stats. I raised 2500 bugs in 12 years, then moved to a company where I raised a thousand bugs in only 19 months.
Presuming that a typical year has 252 working days, this gives me rate of 2.5 bugs per day or 12 per week (compared to an average 0.8 per day or 4 per week during the last 12 years).

That means the rate of identified defects has increased by the factor of 3.

What do these numbers tell about me or the software-under-test, or the company and what does it tell about the developers who introduce these bugs?
Do these numbers really have any meaning at all? Are we allowed to draw a conlusion based on these numbers without having the context? We don't know which of these bugs were high priority, which ones weren't. We don't know which bugs are duplicated, false alarm and which of those look rather like they should have raised as a change request.
We also don't know what is the philosophy in the team. Do we raise any anomaly we see or do we first talk to developers and fix it together before the issues make it into a bug reporting system. Do we know how many developers are working in the team? How many of them work really 100% in the team or less, sporadically, etc...Also, does management measure the team by the number of bugs introduced, detected, solved or completed user-stories, etc.? May the high number of identified issues be a direct effect of better tester training or are the developers struggling with impediments they can/cannot be held responsible for and these bugs are just a logical consequence of these impediments? Are there developers who introduce more bugs than others?

As is with these numbers, they are important, but they serve only as a basis for further investigation. It's too tempting to use these numbers as is and then draw one's one conclusions without questioning the numbers.

How developers see their code

The idea of this cartoon was born after a conversation with a developer who didn't intend to clarify whether a certain piece of code was working as expected.
 The developer stated: "by looking at the code, I know that it works".
Actually, he wasn't at fault, but it was kind of amusing for me to see how different developers think compared to software testers.

I don't believe in code-snippets that I see on a piece of paper or checked-into some source code management system. I want to see this thing run, fly and rock before I make a statement that I like what I have seen. Besides, it also reminded me to another developer statement I've accidentally witnessed many many years ago and I will never forget that phrase which was: "I haven't tested it, but the implementation looks great".

To be honest, I can't tell here whether the developer said that to himself to blow his own horn or whether he was talking to another developer to compliment on his work.

However, after all these years being involved in many testing projects and having developed software myself long time ago, I have always marveled developers' ability of innocent look at their code like they constructed a beauty, only to learn a little later from a critical thinker that either half of it is missing or not working as intended. When I was developing software my own, I was always uncertain whether I did the right thing and I asked the customer several times, if this is really how this thing should work. But that was 20 years ago and we didn't have any testers at that time who served as a protective barrier between development team and customer. The customer was coming to us - developers - every six weeks to tell us where we were wrong. We faced these customers directly. Maybe that made a difference.

Selfie Bugs

These bugs were inspired by Geri Müller