Over the past number of years working as a Scrum Master, I’ve been lucky enough to experience quite a breadth of projects, throughout a number of organisations with varying degrees of Business Agility. Also, working for a consultancy renowned for Software Quality, I can’t help but have a particular interest in the way software quality, and how it is embedded in software delivery, varies not only from company-to-company, but from team-to-team. Here is my essence of the “Agile Tester”.
In many cases, this is of course influenced hugely by organisational or localised culture, but there can still be substantial differences between teams that fall under the same cultural umbrella. This has left me wondering, why?
I believe one of the key reasons for this comes down to the role of the “Agile Tester”, and how this is evolving out of necessity to adapt to a world where organisations are now beginning to recognise the true value of high-performing Agile teams.
Over the course of this post I’ll be taking a look at the traditional role of a software tester, the technical and personal skills they typically possess, and how this compares to the role of the new-age “Agile Tester”.
The Traditional Software Tester:
Although I am actually a qualified software tester, I definitely wouldn’t hire myself!
In a previous life as a Business Analyst, I was exposed to a of bit of testing from time to time, and was quick to learn that I didn’t possess the technical know-how, the extreme attention to detail, nor the patience to make it as a great software tester. I was happy to leave that to the experts!
One phrase that stuck with me from my early days in training within Expleo was that;
A good tester will find that hard-to-catch defect, but a great tester will make sure it gets fixed
This to me sums up what a typical quality analyst (QA) is all about. Their job is to come up with a plan to verify that the software is behaving as described by the product people responsible for coming up with the requirements for the product. They are viewed as the sole gatekeepers for quality. This in turn also means that if a bug sneaks past them into production, that it will be their neck on the line. This creates a mindset that the quality analysts must ensure everything is thoroughly tested to prevent the ‘people in fancy offices’ swinging by their desk with a brown box when they get it wrong. They are actively rewarded for finding bugs, and many will get that feeling of accomplishment and success when finding their 47th bug of the day.
It isn’t necessarily a bad thing that the quality gatekeepers want to make sure that they catch every single issue when the code drop arrives in their test environment. However, if you strip it back and look at the motivations here, the QA is primarily focussed on their job, of finding bugs and getting them fixed. If the developer builds in a bunch of bugs into their code, this just gives the QA even more opportunities to raise a new bug in Jira, which they can show off to their other QA colleagues.
There are numerous studies out there that discuss the cost of finding and fixing bugs at different stages in the product development lifecycle, in fact Expleo recently released one – 9 ways to drive business agility with quality assurance in the 2020’s.
So it’s pretty clear to us that finding and fixing issues as early as possible (shifting quality left, that popular but often misunderstood phrase) is a good thing. So how can we actually do this, and how does the role of the tester need to evolve to enable this?
The Agile Tester:
One of the biggest shifts for a QA, or for any Agile team member for that matter, is that they stop working for themselves and start working for their team. Each team member should be able to understand to a reasonable degree what the impact of their actions have on their team members.
Expleo offer training courses in the realm of “Agile testing”. Try our ISTQB® Certified Tester: Foundation Level Extension – Agile Tester.
David Dwyer is a Principal Consultant at Expleo. He works primarily within the Agile Enablement space, helping organisations improve their own Business Agility, by working with all areas from team level, right up to C-Suite. David also has a background in business analysis, and as such is fixated on improving ways of working and value streams at all levels of an organisation. He is qualified to deliver the IC Agile Fundamentals training and has completed a vast array of training himself, from IC Agile Team Facilitator and IC Agile Product Owner, to the BCS Diploma in Business Analysis, just to name a few. David believes firmly in “Learning by Doing” and can bring a good blend of academic knowledge and real-life experience to his training.
