In this guest post, Agile test experts, Lisa Crispin and Janet Gregory, share their views on DevOps and Software Quality

Close to a decade ago, the DevOps movement grew out of agile development. It was defined as the intersection of “Dev”, “Ops”, and “QA”. (Source: Wikipedia)

Around this same time, the term “continuous delivery” (CD) was popularized by the seminal book by Jez Humble and David Farley. The principles of continuous delivery, as explained in their book, reflect agile principles and the ideas in our own book Agile Testing: A Practical Guide for Testers and the Whole Team, which is referenced in Continuous Delivery:

• Build quality in
• Work in small batches
• Computers perform repetitive tasks, people solve problems
• Relentlessly pursue continuous improvement
• Everyone is responsible

Whole Team Responsibility for Quality

DevOps is congruent with the whole team approach to agile testing that we teach in our books and courses. Operations staff, historically responsible for making sure the production site is functioning properly, may need to learn to code – because much of modern infrastructure is in the “cloud” and configuring it requires writing code.

Team members, that is to say, everyone involved in delivering software to customers, including testers, need to learn to manage operations – configuring continuous integration (CI) and delivery pipelines, as well as monitoring production use of the product. “Infrastructure as code”, like all production code, requires testing so that we can have confidence in it.

Testing begins as soon as we have feature ideas. These can come from the business or the delivery team. We testers start asking questions right away. “Why would we do this feature? How will we test it?” We help our team focus on value to the business and our customers.

Our CI and CD should include automated test suites. We ask ourselves – what should we learn from each test suite? What should happen when tests fail? What other testing activities need to be included in the pipeline, even if they might be asynchronous – exploratory testing, accessibility testing, security testing, performance testing, etc.

When we have answers to these questions, we communicate them to the business stakeholders. They’re responsible for deciding what should be delivered to customers. They need to be aware of all the risks.

Circles for Everyone

In the chapter on DevOps from our book, More Agile Testing: Learning Journeys for the Whole Team, we created our own Venn diagram that reflects our view of DevOps. It includes the business stakeholders because, without them, we don’t have a product to test.

In this context, “Dev” refers to programmers, the people who write production code. We think of everyone involved in delivering a software product, including testers, designers, operations people and more, as “developers”. However, since so many people equate “developer” to “programmer”, we called testers and testing out explicitly in our diagram. The intersection is of the entire software team, including the people who do testing, who write code, who configure infrastructure, and who make business decisions.

We also recognize that we may need UX designers, database experts or anyone else who can help us successfully deliver value to our customers in a timely manner. We could add more circles to our diagram!

Testing is the heart of DevOps. We hear terms today like “continuous testing” that reflect this. We also hear terms like “shift left” that go against the idea that software development is a continuous loop. We learn from asking questions, we learn from monitoring production use, and we deliver valuable features accordingly.  

We like having the “Test” and “Biz” circles in our DevOps Venn diagram. Whichever visualization you prefer, as long as you’re always testing and always involving the business stakeholders, we approve.

About the Authors

Lisa Crispin (@lisacrispin) is a tester who enjoys sharing her experiences and learning from others. She is the co-author, with Janet Gregory, of More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley, 2014) and Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009). Lisa is a tester on a fabulous agile team. She specializes in showing testers and agile teams how testers can add value and how to guide development with business-facing tests. Her mission is to bring agile joy to the software testing world and testing joy to the agile development world. In 2012, she was voted by her peers as the Most Influential Agile Testing Professional Person, and given this award at Agile Testing Days.

Janet Gregory is an agile testing coach and process consultant with DragonFire Inc. She is the co-author with Lisa Crispin of Agile Testing: A Practical Guide for Testers and Agile Teams, and More Agile Testing: Learning Journeys for the Whole Team. She is also a contributor to other software development books. Janet specializes in showing agile teams how testers can add value in areas beyond testing the software after it is built. She works with teams to transition to agile development and teaches agile testing courses worldwide. She contributes articles to publications and enjoys sharing her experiences at conferences and user group meetings around the world. Her peers voted as the Most Influential Agile Testing Professional Person in 2015.

Recommended for You

Testing as the Driver Towards a DevOps Culture
Can There Be Testers in Scrum?