All posts by Markus Gärtner

The BDD pitfall

Last week I went to the 2bd SoCraTes conference, the German Software Craftsmanship and Testing conference. We did two days of open space discussions, and we all had great fun. One thing though that caused me some extensive amount of trouble, was the amount of sessions around BDD.

Some time ago, I wrote about the given/when/then-fallacy. But this time was different. Despite the amount of emphasize that BDD puts on the ubiquitous language, I was shrugged by the fact that folks were pointing to different things while talking about BDD: It seems BDD suffers from the same thing that it tries to prevent: having a common understanding about stuff.

I don’t know where this particularly comes from, and I also saw a couple of bad scenarios when it comes to the usage of tools like Cucumber or JBehave. I don’t consider myself a BDD expert, and people pointed out that I do something different around acceptance tests. Still I thought to expose some of my thoughts about some of the examples that I ran across recently – and helped out improving. Here’s my though process on two of these scenarios.

Continue reading The BDD pitfall

My future wishes for software testing

Huib Schoots approached me late last year regarding some contribution for the TestNet Jubilee book he was putting together. The title of the book is “The Future of Software Testing”. I submitted something far too long, so that most of it fell for the copy-editing process. However, I wanted to share my original thoughts as well. So, here they are – disclaimer: they might be outdated right now.

Continue reading My future wishes for software testing

The Testing Quadrants – We got it wrong!

The Testing Quadrants continue to be a source of confusion. I heard that Brian Marick was the first to write them down after long conversations with Cem Kaner. Lisa Crispin and Janet Gregory refined them in their book on Agile Testing.

I wrote earlier about my experiences with the testing quadrants in training situations a while back. One pattern that keeps on re-occurring when I run this particular exercise is that teams new to agile software development – especially the testers – don’t know which testing techniques to put in the quadrant with the business-facing tests that shall support the team. All there is, it seems, for them is critique to the product. This kept on confusing me, since I think us testers can bring great value. Recently I had an insight motivated by Elisabeth Hendrickson’s keynote at CAST 2012.

Continue reading The Testing Quadrants – We got it wrong!

Actually, there are best practices

A while back I ranted about best practices. Among the things I found in that particular blog entry is that there are quite some definitions for the term “best practice” out there. Nowadays, if it’s not on google, then it doesn’t exist. For best practices google it turns out is quite capable of delivering a definition. Although I resonate with the principles of context-driven testing, I recently found the second principle unhelpful. The second principle states

There are good practices in context, but there are no best practices.

Like many other people that I respect I used to start ranting about best practices whenever people would ask for them. Particularly in training situations, though this does not help so much. J.B. Rainsberger‘s introduction to the Satir Communication Model helped me understand why that is.

Continue reading Actually, there are best practices

How would you test this: Passenger Airline System

This is an experience report that falls in many categories at the same time. I think the most remarkable one is the personal fail category (hooray, I learned something!).

As a consultant I do some fair amount of traveling. Most of the time I stay on the ground, though on my most recent trip to San Jose, CA for Test Coach Camp and CAST that was not an option. So, while lying jetlagged in the hotel room, I decided to blog about my trip here, and why I ended up testing a passenger airline system, which bugs I found, and which follow-up tests I can imagine to run from here.

Continue reading How would you test this: Passenger Airline System

Dear Management,

Dear Management,

I owe you an apology. I have misled you by listening to someone who misled me instead of building my own opinion based on the sources that someone lied out. That said, I have been wrong by repeating rants, and inventing my own once based on a false premise. As a math teacher of mine once explained to me: Based on a false premise you can proof anything.

I found people willing to challenge my belief system, and I thank these people for that. They made me go the hard path to building my own opinion on the topic, and on the sources that the one who initially misled me pointed to. I was amazed that I came to a different understanding. A similar one in some sort of ways, a different one in the most basic claims of that other person. I am thankful for having the opportunity to learn something from this.

And now, beware alpha animal like betrayer of my thoughts. You not only lost a follower of your rants when I reached my own insights, but you also lost my respect. From now on I will tell others about my perspective on things, and where I think you have been astray. I will provide my own picture, and criticize your ideas wherever I feel it’s appropriate. I will warn others from you, if you cannot back up your claims with references. I can.

Sincerely yours
learning employee, and hardest critique.

An Afternote

I didn’t relate this to any real thing that happened in the text in the hope that you will notice how and where you have been misled in the past. Instead of being depressed about it, recognize your failure, learn from it, and confront the other person with your new insights. The worst thing that might happen is that you find out that this particular person is not interested in debating. In that case make sure to turn your Bozo filter on. Things could be worse.

My biggest take-away from Bug Advocacy

At times I find quite interesting things in topics that I don’t seem too particularly interested in. A recent example – again – comes from Let’s Test in May 2012. While at the conference, I read through the program and thought that I don’t need to learn anything new from recent trends in bug reporting. Preferring to work on Agile projects, I don’t think I will use a bug tracker too much in the future.

On the other hand, I knew that I had signed up for BBST Bug Advocacy in June. So I kept wondering what I will learn there, and whether it will be as work intensive as Foundations was. I was amazed at some things. This blog entry deals with my biggest learning: for building blocks for follow-up testing – something I think a good tester needs to learn regardless of their particular background.

Continue reading My biggest take-away from Bug Advocacy