5 Ways Agile Development Changed QA

In the 90s, products didn’t make it to market until 2-3 years after a business need was validated. If the product failed to stay relevant, updating it usually took too long.

Until then, software development followed a step-by-step approach (known as the waterfall method) starting with requirements and ending with deployment. Only after one phase was complete would the next begin. Continuing with this methodology couldn’t possibly speed up lead times or get applications to market faster.


No more saving testing until the end

Remember when software came on CDs?

Yeah, well those CDs had to be designed, manufactured, packaged, and shipped. No wonder there was a lengthy quality control process at the end of development. No one wanted to be responsible for recalling thousands of CDs.

When I first got into QA, everything was delivered via physical media, and so if you had a critical bug in your final shipping product, the cost was pretty significant to actually recall all of your disks and then issue new ones.

Aaron Dolberg

With continuous delivery, it’s important that QA happen continuously as well. Testing can occur on one feature while development is working on a different feature in the same sprint. Testers have also adapted to checking parts of a feature as they become available.

QA teams don’t always have weeks to analyze requirements and create test cases in isolation. They have to think on their feet, rapidly developing new test plans as products evolve.

Greater reliance on automation

With so much attention now spent on new feature development (rather than creating a large product in one go), there’s a greater need for QA automation.

Teams need to feel confident that while they are adding new functionality, no existing functionality is being put at risk, and in most teams, there isn’t enough time between releases for thorough manual regression testing.

QA engineers now have a constant eye on what can be automated. During manual testing, they need to identify tests that can be integrated with existing automation so that regression testing can keep up.

QA now shapes product design

QA teams haven’t always had a say in project requirements and how those requirements would be satisfied. Typically, they were handed down the project requirements and then they would begin creating tests to validate whether or not those requirements had been satisfied.

With the growing focus on the customer experience, customer satisfaction has become the responsibility of every core business function. As a result, product development is now far more collaborative.

Greater focus on communication over documentation

People over process is key. Too many pre-defined processes just get in the way.

The evolution of QA is not WHAT has changed, but rather HOW it has changed. QA is still responsible for analyzing and validating requirements, developing and executing test cases, finding opportunities for automation, and assisting in the resolution of bugs.

But everything is much more fluid.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Agile Manifesto

Communication and interaction between teams as new changes and requirement arise are what demand improvement. With waterfall development, breaks in the process are solved with clearer documentation. Agile teams ask themselves, how can we improve communication? This holds true for co-located and dispersed teams. One of our top testers, Zuzana Cechivska, describes the difference in her own work experience:

On the waterfall projects, as the testers we were just submitting tickets but we didn’t know which developers were responsible for fixing. We mostly communicated just through the tickets. The developer changed the ticket state to ‘fixed’ and if tester didn’t agree they wrote their comment and developer replied and so on.  In agile, I knew exactly who from the developers was responsible for which feature. I could go directly to their desk to discuss. They used to call us as testers to their desks to show their solutions or they came to our desks so that we will show them what is not correct.

Zuzana Cechivska

Sprint planning, daily stand-ups, and sprint reviews are additional avenues where issues get fleshed out. QA takes an active part in any discussion of new tasks, unresolved problems, and where the product is headed.

The temptation to leave testing to customers

Agile development can be a double-edged sword for teams that practice it. Releasing imperfect products on purpose is widespread nowadays, with the heavy focus on speed to market. Cechivska, puts it this way:

I started in June 2007. At that time there was a waterfall model—applications were developed more slowly and there was time for proper documentation of everything and testing was coming as the last stage and everything was quite precise I would say. At least at the projects I was working on the focus on quality was very high. Over time we moved to agile and apps are developed very fast and often goes to the users more buggy.

What matters is the speed—how fast the app and new features can be released to the users.  There is an approach that the users will report problems and they will be fixed on an ongoing basis while the app is already in use.

Zuzana Cechivska

“The Customers should be held accountable for creating the Acceptance Tests!”

Elisabeth Hendrickson

Clearly, testing is not the customers’ job.

Working with QA professionals is better for developers, too, because they won’t have to worry about urgent hotfixes ruining their weekend plans.

Jumbotron image