Successful conversations are central to agile teams. As it states in the Agile manifesto:

“Individuals and interactions over processes and tools”

With this emphasis it is no surprise that many of the agile approaches adopted by teams today focus on enabling successful conversations:

User Stories –  “3 C’s – Card, Conversation, Confirmation.” Ron Jeffries

Behaviour Driven Development(BDD) – “The single most important part of BDD is the conversation.” Liz Keogh

Three Amigos –  “Conversations between the team to gain a shared understanding.”

Conversations are hard!

The problem is good, valuable conversations are incredibly hard to have. Most of the teams i’ve worked with have found it difficult to have successful conversations. In some ways i think thats why so many teams “Doing BDD” jump straight to the tooling. It’s so much easier to write some feature files on your own rather than actually have a conversation.

We all spend most of our lives dodging difficult…

The world of software companies is full of testers and test departments named as Quality Assurance. There is a long ongoing quarrel if QA and Test is the same or not. Long story short, no they are not the same! But a person working in QA needs a lot of skills a good tester has.

My official job title is QA Lead, but I deliberately use the term Test Lead and have it proudly in my signature. Because that’s what I am doing, and that is even what my job description says. Calling software testers by the name of quality assurance implies for many that there is a step in the “production” process that assures the quality. And this is wrong!

Quality Assurance is a term coming from the world of manufacturing. People working in Quality Assurance are monitoring and auditing the production process and keep an eye on it, that…

The question of whether testers prevent bugs or find them is a fairly regular tester conversation.

When you find a bug in the software you have clearly found a bug. It makes no difference whether you were actively testing the software, trying to use the software, or simply clicking around randomly, by performing some actions and recognising that a problem occurred you were testing.

Many testers do much more than testing the actual software product and many want to somehow define what these additional things are. Actions like reviewing requirements, planning releases, training users can all fall to testers. So at what point does testing really start?

Richard Bradshaw argues that finding a bug in the requirements is still just finding a bug. You might have found it earlier but you hadn’t prevented it. A mistake in requirements can still be considered a bug. Your knowledge of the system, the…

The spiral method is just one example of a Agile hybrid.

Many organizations have self-titled themselves as Agile. Who wouldn’t want to be Agile? If you are not Agile, aren’t you by definition clumsy, slow or dull? Very few organizations would sign up for those descriptions; however, Agile in the world of software development, enhancements and maintenance means more than being able to move quickly and easily. Agile means that a team or organization has embraced a set of principles that shape behaviors and lead to the adoption of a set of techniques. When there is a disconnect between the Agile walk and the Agile talk, management is often a barrier when it comes to principles and practitioners are when it comes to techniques. Techniques are often deeply entrenched and require substantial change efforts. Many organizations state they are using a hybrid approach to Agile to transition from a more…

tl;dr This post is an attempt to codify my thoughts about how to succeed with end to end integration testing. A toned down version of this post is part of the Storyteller 3 documentation. 

About six months ago the development teams at my shop came together in kind of a town hall to talk about the current state of our automated integration testing approach. We have a pretty deep investment in test automation and I think we can claim some significant success, but we also have had some problems with test instability, brittleness, performance, and the time it takes to author new tests or debug existing tests that have failed.

Some of the problems have since been ameliorated by tightening up on our practices — but that still left quite a bit of technical friction and that’s where this post comes in. Since that meeting, I’ve been essentially rewriting our old Storyteller testing tool in…

One problem I hear repeatedly from people is that they can’t find a good place to start talking about scenarios.

An easy trick is to find the person who fought to get the budget for the project (the primary stakeholder) and ask them why they wanted the project. Often they’ll tell you some story about a particular group of people that they want to support, or some new context that’s coming along that the software needs to work in. All you need to do to get your first scenario in that situation is ask, “Can you give me an example?”

When the project or capability is about non-functionals such as security or performance, though, this can be a bit trickier. =

I can remember when we were talking to the Guardian editors about performance on the R2 project. “When (other national newspaper) went live with their new front page,” one…

Cultural Fit

I note a recent spate of articles advising employers to “recruit for cultural fit”. And the inevitable backlash against that advice. Like most advice, this simple soundbite conceals a whole can of worms.

Where Are We At?

If we’re happy with our current “culture”, then by all means hire for “cultural fit”. We will likely hire new people that look the same, act the same and think the same as those folks already in the organisation. And thereby reinforce our existing culture and status quo. Which, if we’re happy with it, is what we want, right?

But if we ponder for a moment and conclude that our current “culture” is more of a hindrance than a help, we might want to look to a future in which the culture is different from how it is now. Maybe, markedly different.

“Until I came to IBM, I probably would have told you that culture…

Waking up a bit early to pack my stuff and check out before breakfast. I am a bit tired, but I guess I also got used to it.

Fun moment of the morning was to receive the newsletter from Testing Circus about the May issue, featuring the guy I spend the three past evenings with playing board and card games. Erik Davis! Great job, Erik!

I had breakfast and a chat with Emma and Dan Ashby. So far I only had the chance to shake hands with Dan.

Jean-Paul Varwijk “ISO 29119”

The last day went by way too fast. I decided to visit Jean-Pauls session on ISO29119, which was a good choice. It was not only good talk, but also a great discussion afterwards. I already knew a big bite before that talk, but I got also a good portion of new information lighting the spirit to fight…

My second morning under the Swedish sun went better and my alarm woke me up. At the breakfast table I was joined by some new and tired faces and had good chats with them. Again I got some info about sessions I missed the day before.

After breakfast I had a short but inspiring chat with Michael Bolton.

Guy Mason’s “Utilizing Automation Tools in a CDT environment”

The morning session I chose was “Utilizing Automation Tools in a CDT environment” with Guy Mason. A very interesting session, because it described the idea that Richard Bradshaw propagates about “automation in testing”, but coming from a bit different angle. Since this is a topic that I currently try to establish at work, I was all the more interested in this discussion, if all arguments and approaches I found so far, were confirmed and needed a new look on them. Guy’s message was to use automation…