Reflections on an Agile Testing Manifesto

Reflections on an Agile Testing Manifesto

In 2013 we did a talk on Agile Testing at a conference. We wanted a memorable way to summarize the key learnings of the talk. Inspired by the agile manifesto we decided to try an agile testing manifesto.

Here is what we wrote:

/Users/karengreaves/Dropbox/Growing Agile/Images/TestingManifesto.jpg


We had no idea at the time just how well the manifesto would resonate with people. It started slowly with a few retweets of the slide, and since then has led to blog posts and translations as more and more people have contacted us to say how much they love it.

To date it has been translated into Spanish, Portuguese, French, Ukrainian and Russian.


We had no idea the message was so universal. The process of having people offering to translate something you have written is both humbling and rewarding.

Recently when adding the latest translations in Ukrainian and Russian we reflected a bit about what we’ve learned through having some of our work translated, and how that relates to agile teams.

  1. Translations work on the basis of trust. We are trusting complete strangers to convey our message with the same intention in a language that we don’t understand. And yet we find it easy to give trust in this process. We think it might be because people doing this are doing it from a place of passion and belief in a shared vision of agile testing, rather than for money. Trust is something so important in agile teams, and people think it is hard to create. Yet we have managed to create these high trust exchanges with complete strangers, simply by having a shared purpose and giving trust. Perhaps the answer is not as hard as we think it is.


  1. It is very difficult to spot even basic errors in a different language. Because of the images involved, usually translators send us the text and we cut and paste it into the images. However, we usually need to ask the translator to double check the image, because it is VERY difficult for us to spot even a simple error like cutting a character off when cutting and pasting, as the language is so foreign. It’s even more difficult in languages like Russian that use a different alphabet. This makes us wonder about how we can make noticing issues in other work more (or less) difficult. If it is easier for a native speaker to spot spelling errors, what would make it easier for a tester to spot issues? Understanding the domain language better? Understanding code better? Instead of focusing directly on being a better tester, are there some complimentary skills that might make it easier for us to do some of the things we need to do as testers?


  1. Sometimes writing is better than speaking. We have worked with teams in many countries who spoke many languages. Karen especially remembers working with a Brazilian team. They used to communicate via Skype chat, because it was easier for them to understand each other in writing that it was to have to understand both the accent and the content of the message when using their voices. The desire for so many people to translate our  Testing Manifesto indicates to me that a few simple words have created a powerful message that transcends language. Agile teams tend to believe face to face communication is the richest form, but we wonder if this is necessarily true in all cases. More and more with remote teams we are finding that a combination of media: video, sound, images and words can actually be richer than just face to face communication.

So, trust, looking for an easier path and writing over speaking … how fascinating! Who would have thought a talk summary would lead to so many insights and so much sharing over the span of 4 years. Thank you to everyone who has translated and shared the Testing Manifesto.


More from Karen Greaves & Samantha Laing:

Video: AgileTD Monday Talk - Agile in Distributed Teams [min. 23:37]


Video: Keynote Agile Testing Days 2015 - Testers are Dying! [46:35]

About Karen Greaves


We spend so much of our lives at work, yet so many people don't enjoy their jobs. I perform best when I love my job, and I think this is true for everyone. I believe the best way to engage people at work is to make sure they are having fun, making a difference, and getting better at the things they do. I help people build great teams and deliver great software.

My entire career has been in software development, with a significant focus on agile approaches, and enough experience with waterfall to understand it's limitations. I've worked with XP, Scrum and Kanban in many different environments. Today I coach individuals and teams in being agile.