Freedom, responsibility, and testing: lessons for DevOps
“… [F]reedom can be disorienting at first”, notes James Bach, co-author of Lessons Learned in Software Testing. That’s certainly true for us in DevOps.
“Lessons” from testing apply in at least three distinct ways:
- we need to work with testing departments on a day-to-day basis, as they’re frequent and knowledgeable internal customers;
- certain techniques from testing apply in DevOps; and
- at an organizational level, testing faces some of the same dynamics as DevOps, in that outsiders often seen it as only a cost center, and tend to think of it only when something goes wrong.
Previous installments of “IT Ops” have argued we should borrow applicable tools or practices from development or data specialists. Publication a few weeks ago of “How to Adjust to the Changing Face of Software Testing” brings testing into position to make its contribution.
“How to Adjust …” covers too much territory to admit much summarization, but consider how familiar the setting is: a discipline struggling with the roles of outsourcing, factory models, and automation techniques, gropes for ways to apply effective techniques in contexts from mobile games to high-security industrial control. While the lessons of agility and context-sensitivity–adjust the comprehensiveness of automation to fit the patterns of usage and deployment, for instance–sound familiar enough, I find it helps my perspective to read how practitioners in the similar-but-different domain of testing approach them. Even more interesting is to learn how testers emphasize rollback capabilities and “exploration”, especially on large-scale projects.
As quoted in this article, Bach’s point about responsibility works in a couple of directions: certainly as individual testers gain the freedom to depart from rote scripts, they have the responsibility to act professionally. At the same time, though, Bach compares testers (and presumably DevOps) to such other professionals as journalists or investigative detectives: their supervisors have the responsibility to “get out of their way”, and let them do their best. Provision of tools and other artifacts is only the beginning of a solution; most of what happens in testing (or DevOps) is about how experienced experts make the best of those tools.