Many managers think that if they send everyone to a Scrum training and then assign Scrum roles, they’ve successfully transitioned to Agile. If only it were that easy. Moving from traditional software testing to agile testing is especially difficult. I worked as a tester for 14 years. About four years in, management mandated that we […]
Many managers think that if they send everyone to a Scrum training and then assign Scrum roles, they’ve successfully transitioned to Agile. If only it were that easy. Moving from traditional software testing to agile testing is especially difficult. I worked as a tester for 14 years. About four years in, management mandated that we start using the Scrum framework. After a couple of sprints, they couldn’t understand why we didn’t have a fully tested, potentially shippable increment after each sprint. Note, that we had over 20,000 manual tests and no test automation at this point.
For several years, about every six months, senior management assigned a different test manager. Each manager insisted we automate everything but didn’t give us the training or time to do it right. Even more challenging, our culture didn’t change. QA and development were still separate phases and very separate roles. Trying to do Scrum with these constraints was extremely frustrating.
I often wonder what it would have been like if we had had a manager who truly understood and embraced Agile practices and principles. If that manager recognized that testing agility is an evolution that requires patience and buy-in from everyone. Someone who wasn’t afraid to try new things, and openly acknowledge their own mistakes and treat them as a learning opportunity. I wrote the following fictional story as an attempt to reimagine my testing years:
It was 1996 when Jerry started a new job as development manager at a small software company. Jerry was a smart guy who liked solving problems. The president of the company was frustrated with the development team because their last few releases were late, riddled with defects, and didn’t quite meet the customers’ expectations. She brought Jerry on board to fix them.
The team consisted of five programmers. Jerry doubted the problems were due to incompetence. He initially spent his time with the team to fully understand the situation from their viewpoint. They told him that the scope of each release ballooned over time, but the delivery date never changed. They said they didn’t have time for thorough testing. They said they weren’t capable of verifying features from the customer’s perspective.
Jerry went to his office to think. He sought advice from friends at other development companies, bought and read books on engineering project management, then came up with a solution. He put together a slick presentation and invited everyone in the company to a meeting to pitch his idea. Jerry explained that the company had to hire another person whose sole responsibility would be testing. This would give developers more time to code. Plus, a testing specialist would have better skills to identify and isolate defects. Bonus: they could hire someone already familiar with the customer —all for half the cost of a developer. Thus, the role of software tester was born.
Jerry hired someone from customer service who knew the product well and understood the customer perspective: Jan. Jan was a natural at testing. She found and reported loads of defects. Curiously, the number of defects found per build kept growing. The additional work of fixing defects made it difficult for the team to meet their release dates. At first, Jerry thought it was because Jan was getting better at testing and just finding more bugs. Eventually he concluded that something else was going on.
After some data digging and analysis, Jerry realized that the quality of work coming out of development had significantly declined. He met with the team and described what he’d found. He shared reports and graphs that showed development was passing over very buggy work to Jan. After a long open conversation, the team realized that when Jan was hired, they were no longer validating their code as rigorously as before. They believed they could let their guard down knowing someone else was going to test their work, ensuring defects wouldn’t get passed on to the customer. Plus, with the added emphasis Jerry put on the developers to spend time programming and not testing, they figured this was how things were supposed to be.
Jerry was in a pickle. Adding Jan helped the team. She built up a suite of cases. She created a test strategy and a test plan, all of which had been ignored before. She provided a strong QA discipline mindset. Jerry didn’t want to let Jan go, but couldn’t keep operating like this. The team’s numbers were lower than before, and the president was not happy with Jerry. He went to bed feeling hopeless.
The next morning in the shower he had an a-ha moment. What if they involved Jan at the very beginning? Get her feedback on proposed work and have her write test cases sooner so the developers could leverage them. Ask Jan to work closely with the developers so she could point out potential defects as they were being created rather than waiting for them to come to her. This would significantly reduce the cost of re-work. After all, Jerry knew that the further down the workstream a defect remained unfixed, the longer it takes to fix. If he could free up the team from these painful, long, unexpected defects, they would be able to spend more time on planned work.
He thought about his new idea for a week then met with the president and explained his new insight. Jerry warned the president to prepare to see a dip in productivity as the team learned and adapted to this new way of working. It took some convincing, but the president agreed it was worth trying.
Next, Jerry met with the team. Initially, the team was very resistant. Not long ago, they had to adapt to having a separate testing phase. Now they were being asked to do even more work than ever before. Jerry acknowledged there would be a learning curve that will decrease throughput, but, in the end, they would get more things completed faster, with higher quality, without having to work nights and weekends. Jerry told the team that they would run this is an experiment. We will give you significant time to learn and then time to see if our assumptions are correct. If they aren’t, we will adapt. The team agreed to give it a try.
After six months, the team’s throughput had dramatically increased. They added unit tests to their code and verified their code before it went in the build. Jan now had open capacity to perform more exploratory testing. She found some of those sneaky defects that would be found by irritated customers.
Jan mentioned to Jerry that if she automated the acceptance tests, they would be able to execute the regression test on every build. Jan had no coding experience at that point. Jerry sent her to an excellent hands-on coding class. The developers mentored Jan and she was soon automating tests.
The evolution from traditional testing to Agile testing was a success. Along the way, the team and senior management saw the value of continuous improvement. They team started driving new experiments to find new ways to deliver value in a shorter, sustainable, lead time.
Jerry was a fantastic Agile manager. However, he wasn’t the only one responsible for success. The president, while a bit grumpy, was willing to listen and adapt too. Without support from upper management, organizations will never fully realize the benefits of Agile. In addition, Jan and the developers were not in contention with each other. They were happy to work together towards a better solution.
I can’t go back in time and improve my first transition to Agile testing, but I can train and coach others to create and execute a successful Agile evolution. The story above is fiction, but not fantasy. There are organizations out there running like this. Building in testing agility takes time. Even if everyone is on board with the mission, there will still be hurdles to overcome. When the culture is open to it, every day is an opportunity to find a way to improve.
Join NextUp’s Certified Agile Testing & Automation class on May 18-20 to learn how to internalize a testing mindset, key test engineering techniques, automation strategies, and more.