The Agile Architect

The State of Agile QA: The Times Are a Changin'

Quality assurance has long been an important component of an agile team. But times change. The introduction of new capabilities like ubiquitous cloud computing, containerization and microservices changes the way we think about QA. Here's how.

• By Mark Balbes, Ph.D. with Zachary Becker
• April 13, 2018

My friend and colleague at Asynchrony, Zach Becker, has been through a terrifying ordeal. He was diagnosed with kidney failure, specifically IGA Nephropathy, in April, 2015. He spent a  year on and off dialysis waiting for a new kidney from a generous donor. While many of his friends were tested to see if they were a match, ultimately it was through the generosity of his own mother that gave Zach a new lease on life. Through it all, he actually changed his view of QA.

Peritoneal dialysis is the process by which toxins are removed from the patient's blood while they are sleeping at home. For many, this is preferable to treatment at a dialysis center during the day, three days per week. Peritoneal dialysis means that the patient can continue working and have something of a normal life while they wait for a kidney transplant. But it is no picnic, to say the least.

Zach was one of those patients that suffered from "drain pain." During the night, a solution was pumped into his body, then back out taking with it the toxins that were killing him. Some patients suffer "drain pain" caused by the loss of fluid because of this process.

Since Zach works in QA with software, he wondered whether he could make changes to the system that would lessen his pain. Using the scientific method, tracking his changes and controlling variables, he began changing the physical setup of the dialysis equipment. What he found was that by raising the bag of fluid higher, he could reduce his "drain pain" significantly.

What does this have to do with modern QA? We'll come back to Zach later. First let's look at some of the driving forces changing how we think about software quality assurance.

The Cloud Changes QA
The introduction of cloud computing is a game changer for QA. No longer requiring a capital investment in dedicated hardware, cloud computing offers almost unlimited short term access to compute power. Want to scale test your system each night? You can spin up the virtual machines you need, perform your testing, then spin them down. Since you only pay for the time you use, the cost is similar whether you have a few number of perpetually-on virtual machines or a large number of virtual machines for a short period of time.

And that makes the stakes for DevOps and deployment automation even higher. To truly take advantage of the capabilities of a cloud environment, you need to be able to spin up and down both the system under test, the tests themselves, and any supporting tools.

Microservices Change QA
Cloud computing doesn't just change QA, it also changes how we think about architecting software solutions. With the need for massively-scalable systems like Netflix and Amazon, new architectures are required to manage both the complexity of the system and the complexity around large numbers of highly-interdependent developers.

Microservices are one such attempt at simplification. Taking advantage of cloud computing, virtual machines and more recently containerization, a microservice architecture attempts to reduce dependencies on different parts of a system by deploying each piece independently as its own small, standalone service. A small self-sufficient team fully supports one or a handful of related microservices by developing new features, fixing bugs, deploying to production and maintaining that production system. Microservices, built and managed correctly, can be deployed independently, significantly reducing the need for enterprise-scale coordination that the more complex agile frameworks like SAFe attempt to solve.

But microservices pose a new challenge for QA. While maintaining the quality of a given microservice is simplified, the complexity of a monolithic application doesn't disappear. It is simply transferred from the software to the interconnectedness of the systems running the many microservices. So QA has to consider not just the quality of the individual microservice but of the entire web of microservices and systems that support them.

Traditional testing best practices suggests that testing such a complex system would require creating a QA environment that closely mimics the production system. But today's mammoth systems are difficult (if not impossible) to reproduce.

And so the old joke "I rarely test and when I do, it's in production" comes back to haunt us. Because that is precisely what companies like Netflix are doing. They can't realistically test in a QA environment because there is no way to reproduce their production system and conditions. Not only does Netflix test their systems in production, they have created Chaos Monkey as part of their Simian Army technology that actively tries to break their production systems.

IoT Changes QA
The Internet of Things (IoT) is taking over. From thermostats to lights to your refrigerator to your front door, integration of everyday things into the Internet is becoming commonplace.

This means that more and more software projects have not just a mobile component, but also one or more  IoT components. And, as with mobile apps, behind the simple looking IoT device, there is usually a complex server-side application.

QA needs to adapt with IoT. Automated integration testing is no longer just about the "backend" and the "front end" -- it's about ensuring that when the user asks their mobile phone to unlock their front door, that the lock on the front door actually unlocks. Having someone visually observe the door unlock hearkens back to those dark days of manual testing. But perhaps some clever solution involving optical or electrical sensors could be used to provide feedback to the automated tests.

The Transformation of QA
We've seen above some of the ways that advances in technology changes how we think about QA. At Asynchrony, we no longer talk about QA as Quality Assurance. Instead we talk about Quality Advocacy because the QA dimensional space continues to expand.

Back in simpler times, software quality assurance meant testing to confirm that software running on a single computer was built correctly. It was a single dimension of complexity, a point in time when the system was confirmed to be operating correctly.

As we started creating N-Tier systems, QA expanded to a second dimension of complexity. Not only were the individual software components working correctly, but we had to ensure that the multiple tiers were collaborating properly to achieve the desired outcome.

Microservices add a third layer of complexity to QA, ensuring that the web of microservices and their inherent dependencies are collaborating properly to produce multiple, interlaced desired outcomes.

IoT adds yet more layers of complexity, creating multi-dimensional layers of complexity as specialized devices, mobile devices, microservices, cloud infrastructure and of course, our users all interact in a dance of infinite combinations.

And What About Zach?
As promised, let's get back to Zach because his experience is a great example of how quality assurance must change to quality advocacy to address the challenges of modern systems.

To say the least, Zach did not have a quality experience with his peritoneal dialysis. He had a complex computer system in his home, achieving its technical goal of cleansing his blood of toxins. The system not only had a software and hardware presence, but it also had a physical presence, yet another new dimension to quality. And the physicality of the system caused it to fail, at least partially, in its mission: The patient was in severe pain after every use.Zach was lucky. He had the technical skills, wisdom and physical ability to change his personal circumstances. Most patients are not that fortunate.

Zach survived his experience. It was not always obvious that this would be the outcome. Borne from this, his perspective on QA has completely changed and, through our discussions, his views have now influenced the way I think about QA in modern development.

We are no longer bound to the world of electrons, interacting with our software through small screens, keyboards and mice. Our software is all around us, reaching into the physical world. That physicality connects us, directly in some cases, with incredibly complex backend services and systems. And while this has been the case for many decades on a limited basis, we are now surrounded by it, driving next to it on the freeways, and living inside it.

QA now touches everything we do and everything we have with greater and more significant control over our lives and well-being.

So if you work in QA and you think, "I'm just a tester," I pray you think again.