Aiming for Agile Test Excellence
Aiming for Agile Test Excellence
At Test Evolve, we are most definitely striving for agile test excellence. At face value, it suggests a couple of things.
That, "Agile Test Excellence" can somehow be defined
That, if you are aiming towards, you are not at your destination yet.
Will you ever be?
Agile software delivery has been around for a long time now. There are many, many articles on exactly what it is. As an e-commerce testing practice, we would like to believe that most organisations, professing to “be” agile, understand the criticality and the clear role of embedded but independent testers as part of an agile delivery team. But does that mean that “good” agile test practice is well understood by all? Quite possibly not. Notice, we say “good", not “best”. The reason for that being that we whole heartedly subscribe to the context-driven school of testing thought.
“Best” practice suggests a one size fit all approach for every given client or project and we have never seen that to be the case. Context driven testing advocates a pragmatic yet risk based approach, a scalable yet controllable approach, encourages creative thinking and conversation and the “appropriate" level of documentation and produces passionate and motivated testers who spend more time raising bugs and reporting on quality than they do producing documents describing the testing that they will eventually get around to undertaking.
And so for us at TestEvolve, a first key attribute of an excellent agile testing approach is a firm belief in context-driven testing. This is very closely coupled with the way in which you build your team. We happily seek individuals with experience over certificates and passion and motivation over technical capability. We can teach technical, we can’t teach motivation. We still fully acknowledge the benefits that testing certification can bring to an individual and an organisation, but realise that arguably the best thing it provides us, is a common testing language with which to communicate.
Can you be an excellent tester without your ISTQB certificate? Absolutely, no question.
Can you be a very poor tester with your ISTQB certificate? Of course you can.
At the very heart of agile testing is the premise that the primary role of an embedded test team is to provide earliest feedback on code quality. Clearly, demonstrating delivery of business requirements and the raising of bugs are inherent aspects of how that quality is reported on but the emphasis should be on the “frequency” and “repeatability” of these in sprint test cycles.
For the vast majority of our projects and clients, we work in 2 week sprints. If you note above, I mention “in sprint”. If you find yourselves as a test unit operating 2-3 sprints behind development, you are not agile. If you find yourself frantically testing everything in sprint manually only to add technical debt in the form of automation catchup tasks to the backlog, you are closer, but you are not agile.
Now agile is obviously not the only means of delivering software but if your organisation is headed that way, your role as a test team is to stay in sprint with your developers and not drop the level of regression testing coverage from one code drop to the next - it should actually be increasing on a sprintly basis. On a project right now, we have 2 front end code drops a week in addition to a back end API code drop twice a month. As an agile test team, running the required regression testing for each of these manually or indeed dropping the level of regression testing coverage will never be an option, which leads us to automation.
As far as we are concerned, robust service(API/REST) and front end layers of an automation framework are absolutely critical in delivering an agile test service. What is also required to support this is a test team where every single member can contribute code to build the functionality. You should not infer from this that we do not value manual testing - absolutely the opposite in fact. We strongly advocate that aside from regular repeatable regression testing, the other core benefit from implementing a solid automation framework is how it provides your testers increasing amounts of time to sharpen their exploratory and heuristic testing skills, which 9 times out of 10 is how you will find the really nasty bugs. Automation provides you a form of safety harness but it will not record hundreds of blocking bugs - it will very quickly tell you if a new build to an environment has regressed but it won’t hunt deep down for the edge cases, the likes of which you can guarantee your users will find in production if you don’t get to them first.
So in summary, what do we believe Agile Test Excellence looks like?
A team built from passionate, motivated, creative and experienced testers.
People who draw valuable lessons from “standards” in software testing but also question/seek the appropriate test solution for a given situation.
Testing in sprint and providing quality feedback whilst your developers are still working on the feature.
Developing a robust automation framework at service and GUI layers.
Embracing an exploratory testing mindset to work in partnership with your automation approach.
Building a team of testers who are eager to develop their coding skills and encouraged when it allows them to did into their exploratory testing even more so.
