# Shift

Matt Heusser wrote about the question Are testers going away? in a blog entry yesterday. As I started to write a comment on his blog, I noticed that I should selfishly make an own blog entry out of it. So, in case you haven’t read Matt’s entry, go there and read first, maybe.

Last week I showed that the whole math needs to be re-invented, as I proofed that that 1 is indeed equal to 2, thereby boiling down all maths to just -1, 0, and 1. There were some replies, and it was interesting to see that the testers you read my blog entry were indeed critical enough to challenge the proof. Simon Morley, Chad Patrick and Matt Heusser did a great job to counter-proof that there is no such real number, so that between that number and 1 there isn’t any additional real number. So, the proof I showed was in fact flawed right from the start.

# A proof and a challenge

Here is a mathematical proof I came over during my eleventh grade in the year 1996.

Let x be the biggest real number below 1:

```    x < 1
=> 1-x > 0
=> 1/(1-x) > 0
=> 2/(1-x) > 0
=> 0 < (1-x)/2
=> x < x + (1-x)/2
```

since x is the biggest real number below 1, we may conclude

```(x < ) 1 <= x + (1-x)/2
(between x and 1 there is no real number)
=> 1-x < = (1-x)/2
=> 1/(1-x) >= 2/(1-x)
=> 1 >= 2
=> 1 > 2 or 1 = 2
q.e.d.
```

Since 1 is surely not any larger than 2 we may follow that 1 must be equal to 2. That said, the whole mathematics need to be renewed. Since 1+1=2 we can now follow that 2+2=1, since both are interchangeable. Therefore we just have to deal with ones for all positive numbers. Everything is equal to one, just as I proofed.

Now, you can either stick to believe me on this proof and help me in re-defining the mathematics field, or you can challenge the proof that I just showed you. So, either you have to forget everything you learned about calculations in the past 20 (or so) years, or you can start to investigate the flaws of this proof.

It’s the same with other, not so obvious things in our lives. You can either start to believe the evidence you get presented, or start to challenge it, or to challenge it, or maybe to challenge it, or just to challenge it, or even stick with challenging it. Take your pick.

# Inventory-taking

Recently I sat down and asked our bug database about my last four years of being a software tester. Here are some statistics I found in it:

Bug counts

Bug state Count
New 12
Assigned 5
Reopened 3
Fixed 251
Invalid 33
Duplicate 27
WorksForMe 14
Reminder 1
Won’t Fix 16
Later 2
Sum 364

This makes 91 bugs per year, or 1.75 per week. 68.96% of the bugs I opened got fixed, 9.07& are invalid, 7.42% are duplicated, 4.4% will not be fixed, 3.85% could not be reproduced, while nearly 5% of the bugs I opened are still either new, someone works at them or they needed to be reopened.

What does this tell you about me as a tester? Am I a good tester? A bad one? A mediocre? Were my bug reports always clear? Did they motivate the responsible developer to fix them? How did the bad reports distribute over the years?

Now, these are the more interesting questions to ask in order to make any sense on whether I am a good tester or not. Mere bug counts or percentage values do not reveal anything about this. So, rather than managing by the numbers, maybe manage by working with the individuals. The famous paper on software engineering metrics from Kaner and Bond has more on this.

# The Deliberate Tester – Episode 3

The Software Testing Club put up the latest episode from my little testing fable called The Deliberate Tester.

After Peter got introduced to session-based Exploratory Testing in the first episode, he got introduced into software test automation in the second episode. Now, in the third episode Peter is faced with the trade-off between the two.

For the next episodes I started to give Peter a first test challenge that he shall conduct. I am really looking forward on this one.

# Software Craftsmanship week: A brief history

To conclude the software craftsmanship week, I would like to take a brief look on the history of this movement. So, we’ll take a look on the Software Craftsmanship book, on the creation of the Manifesto for Software Craftsmanship, on the writing of the Software Craftsman’s Ethic, The Wandering Book and some apprentice blogs, some conferences, and the software craftsman swap programs from Obtiva, 8thLight, and Relevance. WikiPedia also has a great history on it with some points I won’t mention here.

# Software Craftsmanship week: Deliberate Practice and Learning

Reflecting over the history of the Manifesto for Software Craftsmanship and the ideas we concluded for the The Software Craftsman’s Ethic, so far I just covered two aspects. The key ideas behind the manifesto and the ethic statements is that craftsman care for their work, taking pride in it, they practice their craft regularly, they learn deliberately, and finally they share their knowledge in communities and with peers. So far, we have started our journey this week with on the sharing part, and continued to take a closer look on the caring part in the last two days. Today, we will spent time on deliberate practice and learning parts.

# Software Craftsmanship week: Clean Tests

To some degree I envy programmers for their clear guidelines. One of these set of these guidelines is well-written in Robert Martin’s book Clean Code – A Handbook of Agile Software Craftsmanship. (Personally, I hope that Kurt Häusler will review it this Software Craftsmanship week on his blog.) So, today I decided to write about Clean Tests, and what a book on the topic should cover.

# Software Craftsmanship week: Ethics Revisited

Continuing the software craftsmanship week, today I will take a closer look on the ethics of being a software craftsman. Nearly two years ago, Robert Martin held a keynote talk on Craftsmanship and Ethics. Let’s revisit some points he mentions from the tester perspective.

# Software Craftsmanship week: Apprenticeship in Software Testing

The Mis-education and Re-education of a software tester is a topic that I see discussed heavily. In the past I have reflected back about my personal education as a software tester, and what I had to contribute myself to this. After having read Pete McBreen’s Software Craftsmanship – The New Imperative I started to understand part of the problem. In chapter 2 McBreen explains most flaws of the Software Engineering metaphor. This is my first blog post in the Software Craftsmanship week 2010. I will spend some thoughts on related topics over the course of the whole week. Today, I would like to take a closer look on educational models for testers – in Software Engineering and what clever people have come up with for compensation.