My Agile journey has so far included stops along the way in Project Management, People Management and Quality Assurance. In this post, I’d like to write a bit about how agile (and in particular, Scrum) can help folks in QA, and what software testers can expect to happen over the course of a transition to an agile framework like Scrum.
I truly believe that there isn’t a role in Software Development that stands to gain more from the adoption of scrum than that of the Software Tester. In pre-transition companies, you typically have a dedicated QA Team. They are often large in numbers, and they have one job: save the company from themselves. Every shortcut taken along the way, every misunderstood requirement, every rushed line of code – all land square in the lap of these Heroes.
Make no mistake, these Heroes carry with them a large burden. They’re a group of people who are tired, frustrated and often under-appreciated. Worst, they feel unable to improve how the company operates. They live at the end of the line and they only need to be wrong once to get in the boss’ bad books.
It’s going to get worse before it gets better
So, what does life look like for the QA Tester during a transition to Agile? Well, in the early days of a transition, I’m sorry to report that things will feel worse, sometimes MUCH worse than they were before. Your QA Team will break up and be spread throughout the company, placed into cross-functional teams that include developers and designers. As developers scramble to meet their sprint commitments, mistakes and oversights will increase. You’ll be struggling to keep up with writing test cases, and you’l almost certainly be logging bugs at a much higher rate. If the transition is going well though, you will also find that a higher percentage of the bugs you log actually get fixed BEFORE the feature is ever released to customers.
Early Wins
As your new team begins to gel and discover what it means to work at a sustainable pace, you will find opportunities to truly build quality into the process. Instead of waiting weeks to get your hands on a feature for testing, you will work on it from the moment the feature lands in the backlog. You’ll help to craft the description of the feature along with developers and product owners, and as a QA expert, you will have input into defining the acceptance criteria upfront. You will help lead the entire team to a shared understanding of how the feature will work, and the kinds of edge cases that need to be accommodated.
This shared understanding eventually leads to fewer bugs being logged, which in turn leads to much less time spent on manually testing and retesting each feature. At this point in the transition, things are starting to look and feel much better – Quality overall has started to increase, and you’re not spending your evenings and weekends retesting features that you’ve already tested a hundred times. You probably don’t dread coming in to work anymore.
Taking it to the next level
If you haven’t already, now is the time to make a serious investment in automated testing. In fact, I wouldn’t recommend waiting this long. The moment you find out about an impending transition to Agile, you need to go out and learn about automated testing. Because by this point in the transition, your team’s continued success relies heavily on your ability to focus your manual testing time on new features, almost exclusively. A long, manual regression test lumped in at the end of your project is a surefire way to wreck the release and with it, management’s confidence in “this whole agile thing”. When it comes to true agility in software development, an obsessive focus on automation is what separates the fakers from the makers.
As you spend less time logging, testing and reopening bugs, you can (and must!) increase the time you spend writing automated tests. As your automated test coverage increases, you’ll find that you are now able to release the product more frequently (and with higher confidence). Releasing more often acts as a catalyst to even higher quality. It allows you to spend less time fighting fires and more time focused on the next bit of value you’re going to deliver to your customers. With each successful release, your stakeholders begin to feel a little more relaxed, and people start to trust each other. Imagine that!
Feeling it
Somewhere along the way you will come to realize that not only does your job not suck anymore, but your sense of job satisfaction has actually crept higher and higher with every release. You’re now an integral part of the process from day 1 of each sprint, and the weight of the company no longer rests solely on your shoulders. Most importantly, you sleep well at night trusting that your team is thinking about quality throughout the process.
It’s good to not be a Hero.