Agile Testing – Unicorn perspective

So for anyone not attending Agile testing days 2012, unicorns actually became the theme of a great conference through the collaborative work of peers. It refers to the differences and similarities between /the real world/™ and the unicorn world.

If you haven’t read the previous posts in this series, please do. Also do keep in mind they refer to extremes of perspectives.

Bridging communities
Agile Testing – Traditional testing perspective
Agile Testing – Agile perspective
Agile Testing – Programmer perspective
Agile Testing – Project management perspective
Agile Testing – Context driven testing perspective

About the extremes

My friend and Scout colleague shared with me this great analogy when it comes to discussions about things that people care a lot about. At that time a couple of us were talking about the whole global warming controversy, but it applies to many similar debates, like the one about Agile testing. “How come it is so hard for people to discuss these matters without ending up in a ditch and not getting up?” The essence of this being that if you are of a certain belief in a debate that you care very much about, it is very hard to hold the debate on track (or on the road) with factual reasoning in both directions. While in the ditch, the reasoning will just stay the same and nothing in the discussion will move forward after that.

The real world (unicorn world), the recent experience reports

All of the communities that I have written about have people in them that always end up in the ditch. Unfortunately, those are the real believers and caretakers of the communities as well. So as much as they bring the deeper thoughts of communities forward, I think it is important to know and take a distance when something else needs to be considered, like getting your job done in a good way.

With all these perspectives and models of the world, the most accurate stories I believe are most often told by people that are actually working on software projects. Not five years ago, but NOW and within the last year or two. Like Elisabeth Hendrickson points out in her tweet, shelf life on skills within software development has shrunk rapidly compared to 10 years ago. This means that if you are teaching (or preaching for that matter) anything within software development, doing actual project work is essential to keep up with what your peers already know when challenging your ideas.

The practitioners need to tell their stories, and share the conclusions they have made in retrospect. And people have to listen to them and understand these gifts of knowledge. But beware, we actually have that context thing, where every single person has different experiences of what works and not works in THEIR projects at THAT time with THOSE people involved. And the knowledge sharing does not just happen when you share your experience, but when the right person in the room actually takes those experiences and applies the parts that work into their own project.

Thoughts

That is where I think we need to dig to find out what Agile testing really is in practice and what is hidden behind the words. Apart from already established “Agile testing practices”, I think there are still loads of things that remain to be shared in the continuum of Agile testing.

I have been thinking a lot about this, to figure out where I want to take it. This series turned out to be quite a journey for me, since now I got a much bigger audience than when I have talked to people about this face to face during the last year or so. All the feedback I got on the posts is rewarding in so many ways, and I hope I did not step too hard on anyone’s toes.

The single most rewarding discussion around the topic must have been during PotsLightning before Agile Testing Days. The reason for that? We stayed on track without ending up in the ditch for the whole day! Instead we ended up with a nice list of attributes that great Agile testers /might/ need. Thanks to Maik Nogens, Meike Mertsch, Lisa Crispin, Huib Schoots, Markus Gartner, Jean-Paul Varwijk, Matthew Heusser, Stephanos Livieratos.

What is Agile testing?

These are my takes on some kind of definition for Agile testing:

Agile testing is when a context dependent skill set of a team is utilized to carry out testing activities in collaboration with the basis in an agile mindset.

As an Agile tester I have an agile mindset and I am able to apply my personal skill set according to the product and project context needs. If the skills are lacking, I make sure to either learn appropriate skills or cover the needs with something else appropriate for the situation from my own or the teams collective toolbox.

I would like to say that these possible definitions relate very much to context driven testing, but in a sense that the whole team collaborates on all quality work.

So for the skills needed to carry out great Agile testing? Are there any skills like that which are NOT dependent on context? I might give that a take in a later post, however I consider the “must be able to code” skill a very much context dependent skill.

http://weknowmemes.com/wp-content/uploads/2013/01/unicorns-are-real.jpg