The person or coding agent that changes a user flow should write or update its end-to-end (E2E) test, in the same pull request as the change. Quality assurance (QA) specialists should own what gets covered, review the tests, and do the exploratory testing that scripts cannot. Splitting it this way keeps tests current and keeps testing expertise where it adds the most.
Tests written later fall behind
When E2E tests are written by a separate team after a feature ships, they trail the product. The feature merges, the test is scheduled, and in the gap the flow is unprotected. By the time the test exists, the next change has already landed. The backlog of missing tests grows with every release.
The gap is widening as code gets cheaper to produce. In the Stack Overflow developer survey, 84% of respondents are using or planning to use AI tools in their development process [Stack Overflow]. The DevOps Research and Assessment (DORA) report found that 90% of survey respondents report using AI at work [Google Cloud (DORA)]. If these tools help each engineer ship more changes, more flows change between releases, and a separate team writing tests after the fact falls further behind.
The author of the change has the context
The engineer who changes a flow knows what changed, why, and what the new correct behaviour is. Writing the test at that moment costs the least: no hand-off, no ticket, no second person rebuilding the context.
It also makes the pull request complete. A reviewer sees the change and the test that proves it in one place. If the team treats the E2E check as a merge gate, the test has to pass before the change lands. On GitHub, once required status checks are enabled, all required checks must pass before collaborators can merge into the protected branch [GitHub]. Whether to require it is the team's call.
The same rule applies when a coding agent writes the change. The agent should update the test in the same pull request, and a human should review both. Testing strategy for AI coding agents goes further into that workflow.
QA owns the strategy, not the typing
Moving test writing to authors does not remove the need for testing expertise. It changes where that expertise goes. A QA specialist on a team where authors write tests should own:
- The flow list. Which journeys have E2E coverage, which do not, and why.
- Review. Checking that a new test asserts the outcome that matters, not only that a page loaded.
- Suite health. Watching for flaky tests, slow tests and duplicated coverage.
- Exploratory testing. Finding the failures nobody thought to script.
The role does not get smaller. It moves from typing tests to deciding what they must prove. Will AI replace QA testers covers how the role is shifting.
Readable tests widen who can review
A test written in framework code can be reviewed only by people who read that code. A test written as plain steps can be reviewed by a product manager, a designer or a support lead who knows how the flow is supposed to work. They catch a different class of mistake: a test that passes but checks the wrong thing.
That does not mean everyone should write tests. It means the people who know the product can read them, and the author can ask them to.
Make the rule explicit
A convention only works if it is written down:
- A pull request that changes a user flow updates or adds the E2E test for it.
- The reviewer checks the test as part of the change, not after.
- QA reviews the flow list on a fixed cadence and assigns missing coverage to the owning team.
- A test that breaks because of a change is fixed in that change, not in a follow-up ticket.
How AI Testing Platform fits
In AI Testing Platform, a test is a list of plain-English steps in a YAML file (a plain-text configuration format), so the author of a change can write it and non-engineers can review it (plain-English tests). A coding agent can read existing specs, write new ones in the same format, run them and read the report (for agents). Learning your product from session recordings, product docs and the codebase to propose tests is in beta (learns your product). The platform does not replace exploratory testing, accessibility review or security testing (what we cannot do).