Your tests pass on Friday, fail on Monday
Your test suite passes on Friday. Monday morning after a refactoring sprint, 40% of tests fail. Nothing broke. Your tests just can’t find the buttons anymore.
I’ve seen this pattern play out dozens of times. Teams invest months building Selenium or Cypress test suites. They write hundreds of tests. Then they watch them break constantly during normal development.
The problem isn’t the tools themselves.
Implementation-based testing couples tests to code structure
Traditional test automation targets CSS selectors and DOM structure. When you write a Cypress test, you are saying: “Find the element with the class ‘submit-button’. Click it. Then check if the element with the ID ‘success-message’ appears.”
This works perfectly until developers refactor.
Someone renames CSS classes for consistency. Someone restructures components to reduce nesting. Someone changes the DOM hierarchy to improve accessibility. Functionality works perfectly. But your tests can’t find the elements anymore.
I was talking to the team at Islands last week about this exact issue. They manage dev hours across many client projects. They kept seeing the same pattern. Client teams refactored React components for better speed. Then 30% to 40% of their Cypress tests would fail. Not because features broke. Because selectors changed.
What caught my attention was the maintenance burden. They found that in each sprint focused on code quality, they spent an extra 15 to 20 hours.
They used that time to update test selectors. The tests were supposed to enable faster shipping. Instead they were creating friction.
The AI testing hype misses the point
Here’s where it gets interesting. According to the Test Guild 2025 Report, 72.3% of teams are actively exploring AI-driven testing workflows. But most “AI-powered testing” tools are just Selenium script generators.
They use AI to write the selectors for you. Faster test creation, same fragility problem.
The tests still break during refactoring because they’re still coupled to implementation details. AI doesn’t solve the architectural issue. It just automates the wrong approach.
Intent-based testing tests behavior, not Implementation
Intent-based testing represents a fundamentally different architecture. Instead of targeting CSS selectors, it reads Figma designs and user stories to understand what behavior should exist.
Here’s what this looks like in practice at QA flow. The platform reads your Figma design specs and GitHub commits. It understands that you have a “Submit Payment” button that should trigger a success confirmation. It generates tests that verify this behavior happens, regardless of how you implement it.
You refactor your component structure? Tests still pass.
You rename CSS classes? Tests still pass.
You restructure your DOM hierarchy? Tests still pass.
Because the tests aren’t asking “does this selector exist?” They’re asking “does this behavior match the design intent?”
Forrester recognized this difference when it published its Autonomous Testing Platforms Landscape in Q3 2025. It profiled 31 vendors that combine traditional automation with AI and genAI agents. This isn’t a feature add-on to existing tools. It’s a different category.
Why this matters for DevOps velocity
Less than 20% of testing is currently automated, according to Software Testing Help 2026. Test automation remains a critical DevOps bottleneck.
But it’s not because teams don’t understand the value. It’s because the maintenance burden makes many teams question whether automation is worth it.
Implementation-based testing creates a feedback loop. More tests mean more maintenance. This slows refactoring. Code quality suffers. Teams then hesitate to add more tests.
Intent-based testing breaks this loop. Tests stay valid through refactoring. Code quality improvements don’t create test maintenance debt. Teams can actually increase test coverage without proportionally increasing maintenance burden.
I saw this play out with a team using Timecapsule for project tracking. They had abandoned test automation entirely because maintenance was eating 25% of their QA capacity. When they switched to intent-based testing, maintenance time dropped to under 5%. Not because they were writing fewer tests. Because the tests survived implementation changes.
The philosophical shift
Implementation-based testing asks: “Does this selector exist?”
Intent-based testing asks: “Does this behavior match the design?”
One breaks during refactoring. The other survives it.
This is why QA flow generates tests from Figma designs and GitHub commits, then executes them on every push. The tests are coupled to design intent, not code structure. Refactoring doesn’t break them because the intent hasn’t changed.
Good testing isn’t about maintaining scripts. It’s about validating behavior from design intent.