RSS

With Freedom comes Great Responsibilty

06 Jul

Whatever life holds in store for me, I will never forget these words: “With great power comes great responsibility.” This is my gift, my curse. Who am I?

I’m Spiderman.

As with Peter Parker, I see the same holding true with agile testing. I was recently delivered a course on agile testing and I found myself repeating the above phrase but substituted the word “power” with the word “freedom” – “With great freedom comes great responsibility.”

I see agile as an adaptable framework or more accurately, a set of principles, that allow testers (amongst the entire project team of course) to look outside the “box” (testing processes) and yet at the same time let the framework help guide the testing activities.

 There are of course, certain constraints within an agile project (particularly the duration of an iteration) which means that as a tester, you need not only have to be flexible but also efficient.

I have been on far too many projects that have followed a traditional pattern (analysis, design, code, test – wait that sounds almost like a waterfall) that, in hindsight, weren’t the most effective way of building software.

 Some succeeded, alot failed.

 One particular BUFD (Big Up Front Design) project had a physical separation of the core team (Analysts lived in one area, testers in another and development in another city). There was a distinct lack of collaboration let alone co-operation and a degree of animosity between testers and the analysts. There were numerous changes to the specification within a three month period which meant a re-write of a majority of test scripts (literally thousands of test scripts) – all this without even seeing a working prototype.

This project failed – it was a death march from the beginning which was obvious in hindsight.

 I wonder if this project would’ve fared better if it was developed iteratively? Who knows? Maybe we could’ve discovered the problems earlier (and abandoned the project earlier?) or maybe the physical separation was too big a huddle to overcome?

 Many questions with many hypothetical answers.

 This project suffered, from a testing perspective, from inflexibity. We all wrote test scripts (approximately 14 testers in the team) which kept changing. We adapted but we were no where near efficient. We clung to the “box” (the teams testing process) because that was all we knew. There was no great responsibility because the responsibility was mandated by the “box”.

 From an agile project perspective, the walls on the “box” can change quite quickly – one minute it’s a box, the other it’s a cube. This can be disconcerting for some for it appears that the fluidity of the “box” is chaos but what it really is, is freedom and “with freedom comes great responsibility!”

Good agile, agile done well appears to have a greater degree of freedom in the way testing is approached and performed but with this freedom comes disciple, structure, governance – this is the great responsibility. We value working software yet we don’t sacrifice goodness for sloppiness, constant velocity for speed or good practises for dogma.

 As testers, we understand that the project context helps determine our approach, the freedom to achieve this is based on the context which in turns helps us understand the responsibility we have in delivering our part of the bargain with the project team.

Posted by Brian Osman

Advertisements
 
3 Comments

Posted by on July 6, 2009 in Agile, Testing

 

Tags: , , , , , , , ,

3 responses to “With Freedom comes Great Responsibilty

  1. Sharon Robson

    July 7, 2009 at 11:07 am

    Interesting Brian, I like the concept of the testing “box” but I think that if we consider the sum of testing knowledge to be inside the box, the true skill, no matter the lifecycle applied, comes from opening the lid of this box (a tool box may be a good analogy) and looking inside, selecting some of the techniques to be applied with skill and knowledge to get the best result. I get very concerned that when we think “agile” we think we don’t need to follow any “rules”….in fact I think it is more important to be disciplined and apply our knowledge very carefully. Without the safety net of a more formalised lifecycle we must use what we have at our disposal in the most effective AND efficient way possible. Sometimes that does involve writing documentation or even extensive test scripts….it all depends on what we are trying to test. I think that instead of working “outside” of the box, we need to spend time looking at what we can use from “inside” the box more efficiently.

     
  2. Tim Moore

    July 7, 2009 at 5:19 pm

    Brian, you truly are a SuperHero of software testing. Great Spiderman line…

     
  3. John Watson

    July 8, 2009 at 1:03 pm

    I wonder if there has ever been a BUFD project that was not a Death March. Those poor mortals who suffer from beancounterism fail to realise that signed-off stage gates will guarantee delivery of a product that might conform to specification (verification) but is very unlikely to be fit-for-purpose (validation)within some oft re-negotiated abitrary deadline and spend limit.

    We all know BUFD doesn’t work. Collaboration (somehow I prefer the termto “agile”)does work. But collaboration implies rules of engagement (“this how this team does it”; in other words discipline. And of course the collaborating tester needs to know what criteria they are testing against. I wonder why so little attention gets paid to Outcome Realisation Testing to answer the question “Did we spend our money wisely?”

     

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: