How to have successful conversations

Toby The Testers Blog

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…

View original post 546 more words


QA people are not testers, or are they?

Test Pappy

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…

View original post 501 more words

Do testers really prevent bugs?

Testing the Mind

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…

View original post 958 more words

You Are Not Agile . . . If You Do Waterfall

Software Process and Measurement

The spiral method is just one example of a Agile hybrid. 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…

View original post 644 more words

“Start off with a turd and then polish it” – Really??!!?!

“Start off with a turd and then polish it” – Really??!!?!.

Succeeding with Automated Integration Tests

The Shade Tree Developer

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…

View original post 2,134 more words

Negative Scenarios in BDD

Liz Keogh, lunivore

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…

View original post 366 more words