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, a lot 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 inflexibility. We all wrote test scripts (approximately 14 testers in the team) which kept changing. We adapted but we were nowhere 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
Your details have been submitted and we will be in touch.