(E27) Responsible Automation with Paul Grizzaffi: Automating for Value, Not for Process
In this episode of Developers Who Test, host Chris Harbert sits down with Paul Grizzaffi, a seasoned test automation architect who coined the term "responsible automation." Paul joins as an independent expert to unpack what responsibility in automation really means, framing it entirely around value: if the work you automate is not adding value, or if a different choice would have delivered more value sooner, you are probably being irresponsible with your automation. Everything, he argues, should ladder up to a program, organizational, or corporate goal, with automation existing in support of testing and testing in support of delivery.
A large part of the conversation centers on the danger of process-driven automation, where teams automate simply because their Scrum, Agile, or DevOps playbook says they should. Paul warns against chasing the last mile of full automation coverage and building Rube Goldberg machines, noting that sometimes it is more valuable to let humans handle work that is not economical to automate. He encourages teams to evaluate effort versus payoff through a cost benefit and opportunity cost lens, and to consider automating data management, data creation, and environment setup rather than reflexively automating tests. Chris and Paul also dig into the manual to automation-assisted to autonomous spectrum, and what humans still do better than machines: free thinking, lateral thinking, noticing the unexpected, and stepping into the mind of a confused user.
The two veterans compare the current AI moment to past industry overcorrections, including how Agile lost its discipline when it went mainstream and how the JavaScript ecosystem reintroduced dependency and version chaos that the Java and C# world had already solved. Paul returns repeatedly to trust and opacity: you cannot trust what you do not understand, and AI's black-box nature makes oversight harder. He cautions against over-trust and over-reliance, reminding listeners that AI is still software and will have bugs, so an AI-generated list of test cases can be both incomplete and full of invalid cases.
Paul reframes the tester's role away from gatekeeper and toward risk reporter, with the release go/no-go decision belonging to the team but with the business holding veto power because it understands the contracts, penalties, and tradeoffs. Chris shares a personal story about finally saying "I don't think we should go," and Paul offers a practical reframe: rather than litigating what was and was not tested, surface the concrete risks (security, legal, penalties, schedule risk, aging hardware) and let the business make a conscious, context-specific call. They discuss the trap of QA always being seen as the bearer of bad news, and why speaking in risk and value rather than fear keeps testers credible.
The episode closes on getting started and on testers earning a seat at the table. Paul touches on API versus UI testing and on testers getting involved earlier in architecture and design, using a memorable example: piping an entire log file into an LLM just to extract exceptions is like swatting a fly with a Buick when a regular expression is cheaper, faster, and more reliable, though AI shines when asked to find neighboring causes or project where future problems may arise. He advises teams to focus on value, watch where chronic problems and time sinks live, and fight to "take a breath" mid-sprint to work smarter. For those looking to grow, especially junior practitioners, Paul recommends finding friendlies, speaking to others in their language of risk and opportunity cost, framing work as partnership, and making confident suggestions rather than asking permission. You can find Paul on LinkedIn, Twitter, and Bluesky, and at his blog, theresponsibleautomation.wordpress.com.
Key Topics:
- What "responsible automation" means and why value, not process, should drive every automation decision
- The danger of process-driven automation and chasing full coverage when humans may be the better choice
- Using cost benefit analysis and opportunity cost to decide what is worth automating
- Automating data management and environment work, not just tests
- The manual, automation-assisted, and autonomous spectrum, and what humans still do better than machines
- Trust and opacity in AI, and the risk of over-trusting AI-generated test cases
- Lessons from past industry overcorrections in Agile adoption and JavaScript dependency management
- Testers as risk reporters rather than gatekeepers, and release go/no-go as a business decision with team input
- Identifying concrete risks: security, legal, penalties, schedule risk, and aging hardware
- Matching the right tool to the problem (regex versus an LLM) and getting testers involved in architecture
- Practical tactics for "taking a breath" mid-sprint and for junior practitioners to build influence