By Milić Bogićević, Senior QA Automation Specialist, Tech Tailors QA

Next month I’m heading to a conference where none of the software on display manages a shopping cart or a login page. It manages what happens to water before it reaches a tap, or what gets reported to a regulator after it doesn’t. Water utility platforms, environmental monitoring systems, industrial compliance software.

That’s a different category of software. Most QA processes weren’t built for it.

The bug looks the same. The consequence doesn’t.

Most testing practices (the ones taught in courses, sold by outsourcing firms, baked into a typical sprint’s “definition of done”) assume a certain kind of failure. A button that doesn’t work. A page that loads slow. A checkout that drops a customer mid-purchase. Annoying. Costly. Fixable next sprint.

Water and environmental monitoring software fails differently. A sensor reading silently off by a small margin. An alert threshold that doesn’t fire when it should. A compliance report that generates fine and says the wrong thing. Nobody catches it in a demo. Nobody catches it in a sprint review. Somebody catches it during an audit, or after something already happened.

Same size bug. Different consequence.

Water treatment facility with monitoring systems

Why AI-written code makes this worse, not better

The volume of code shipping into this kind of software is climbing, and more of it is AI-assisted every quarter. A CodeRabbit review of 470 open-source pull requests this year found AI-generated code carries 1.7x more defects than human-written code: 2.7x more cross-site scripting issues, close to 2x more insecure deserialization bugs.

Sonar’s 2026 developer survey asked the people writing this code how much they trust it: 96% said they don’t fully trust AI-generated output, and less than half said they always review it before it ships anyway.

A wrong dashboard number is a Monday-morning fix in most SaaS products. In software feeding a regulatory filing, it’s a different category of problem. And it’s being written faster, by tools nobody fully trusts yet.

Industrial water storage tanks and treatment infrastructure

What actually needs to change

Generic “more QA” doesn’t fix this: more headcount, more tickets closed, the same test suite run more often. What helps is testing scaled to what’s actually at stake, not to how a team happens to be staffed. A startup shipping a to-do app and a utility shipping a monitoring platform shouldn’t be tested with the same tolerance for edge cases. Right now, a lot of them are, because most QA gets sold as one product, not two.

We’ve done exactly this for a wastewater management platform already, cutting a QA cycle that used to take two days down to about an hour.

If a missed edge case in your software shows up in an inspection report instead of a support ticket, it’s worth checking whether your testing process actually accounts for that. Most don’t.

At Tech Tailors QA, we specialize in QA for mission-critical software—the kind where every test matters because the real world is watching. I’ll be writing more on this before and after the conference, including what I actually hear from people running QA for water and environmental software once I’m there.

Curious what this looks like in practice? Read the full case study →

Is your water or environmental monitoring software getting the right level of testing? Talk to us about QA built for real-world consequences, not app-store workflows.