My management is pushing for 100% automation using 'self-healing' AI tools to reduce the need for manual QA. I'm worried that while these tools are great for regression, they'll miss the edge cases that only a human would find. How are you balancing AI automation with the need for critical human observation in fast-paced sprints?
3 answers
100% automation is a myth that often leads to a false sense of security. AI-driven tools like Testim or Mabl are fantastic for maintaining stable regression suites because their "self-healing" properties can detect minor UI changes without breaking the build. However, AI lacks the "intuition" to perform true exploratory testing—it doesn't understand user frustration or logical flow contradictions that haven't been programmed. In my current Agile team, we automate about 80% of the repetitive paths but strictly reserve the last two days of every sprint for "unstructured" exploratory sessions led by our senior QA analysts to catch those elusive edge cases.
Does your "self-healing" tool provide a detailed log of the changes it made to the selectors, or are you finding it creates a "black box" where you don't actually know why a test passed?
AI is a tool, not a replacement. Use it to handle the "boring" stuff so your humans can focus on breaking the system in creative ways that a machine could never imagine.
Well said, David. I’ve found that my team is actually happier now because they aren't stuck re-writing brittle scripts every time a dev changes a CSS class. They get to do real testing now.
That’s a valid concern, Charles. To answer you, we use a tool that flags every "healing" event for review in the next stand-up. This prevents the "black box" issue. If the AI changes a selector, we verify if it was a legitimate UI update or if the model is just getting lazy. This human oversight is exactly what keeps the automation from drifting away from the actual business logic, ensuring our "automated" safety net actually remains reliable as the codebase evolves rapidly.