How Testing Keeps Up With Development

Liviu Lupei

Founder & Solutions Architect, Endtest · May 21, 2026

Development has changed faster than testing.

AI coding assistants, code completion tools, and agentic development workflows have made it easier for developers to create more code, revise more code, and ship product changes faster than before. That sounds like a productivity win, and in many ways it is.

But faster development also creates a new problem: more code means more change, and more change means more risk to be tested.

The DORA team at Google Cloud captured this problem clearly in its research on generative AI in software development. AI can improve individual productivity, documentation, and code review speed, but higher AI adoption was also associated with lower software delivery throughput and lower delivery stability. Their recommendation was to strengthen the fundamentals rather than slow development down: smaller batches, better review, continuous integration, and automated testing.

That is the new reality for QA teams.

Testing can no longer be a final sprint activity owned by one exhausted person at the end of the release cycle. If development is accelerating, testing has to become part of the development flow itself.

Testing still matters. The question is how it keeps up with development without becoming the bottleneck.

The short answer

Testing keeps up with development when automated testing becomes a shared team responsibility, not a late-stage QA task.

That means:

• Every sprint should end with automated test coverage for the new features and changes.
• Developers, testers, product managers, and QA leads should all be able to understand what is being tested.
• Test automation should be created during the sprint, not after the sprint.
• Functional end-to-end tests should validate real user journeys rather than isolated components.
• Cross-browser tests should run in CI/CD and on a schedule.
• The test format should be easy to read, review, update, and maintain.
• AI should help create and maintain tests, but the output should not become another black-box codebase.

This is why modern test automation platforms matter.

Classic Selenium and Playwright frameworks can work well when a dedicated engineering team owns them. But for many product teams, any framework can click a button. The long-term problem is whether the whole team can keep the tests updated while the product keeps changing.

Why development is moving faster than testing

AI has changed software development by reducing the effort required to create code.

GitHub's research on Copilot found that developers using Copilot completed a programming task significantly faster than developers who did not use it. In that controlled experiment, the Copilot group completed the task 55% faster.

That does not automatically mean the whole company delivers better software 55% faster. Writing code is only one part of delivery.

A feature still has to be reviewed, tested, deployed, monitored, supported, and maintained. If AI increases the amount of code being produced, the rest of the delivery system has to absorb that extra volume.

This is where many teams are starting to feel pressure.

AI can help developers create code faster. Developers can revise AI-generated code frequently. Product teams can ask for more changes because changes feel cheaper. But every change still has to be tested.

More code plus more change equals more risk.

And that risk usually lands on QA.

Why testing becomes the bottleneck

Testing becomes the bottleneck when development velocity increases but the testing process stays the same.

In the old sprint model, one person or one small QA group was often responsible for automated tests. In theory, tests could be planned early. In practice, that rarely worked cleanly.

The first days of the sprint were often quiet for the automation owner because the UI had not landed yet. The backend might still be changing. The acceptance criteria might still be moving. The designs might not match the implementation. The feature might not be stable enough to automate.

Then, near the end of the sprint, everything arrived at once.

The tester had to understand the changes, manually check the feature, update old tests, create new automated tests, debug failures, prepare regression coverage, and still approve the release.

That is not a process. That is a traffic jam.

When there is too much work at the end of the sprint, teams start making compromises:

• "We will automate this next sprint."
• "Let's just do a quick manual check."
• "This test is failing, so let's remove it from CI for now."
• "The Playwright suite is outdated, so don't rely on it."
• "The Selenium tests are flaky, so only run the smoke tests."
• "We know this area is risky, but the release has to go out."

This is how test automation becomes shelfware.

The tests were created with good intentions. But they were not maintained at the same speed as development. Eventually, they become outdated, commented out of CI/CD, ignored by developers, or replaced by manual checks.

The old QA ownership model does not work anymore

The old model looked like this:

1. Developers build the feature.
2. QA tests the feature.
3. Automation engineers automate the feature.
4. The release is approved.
5. The team moves on.

That model breaks when product teams are shipping continuously.

The reason is timing.

By the time QA receives a stable version of the feature, the sprint is almost over. If only one person is responsible for automation, that person cannot realistically cover every new feature, every changed flow, every cross-browser scenario, every regression risk, and every edge case.

In the AI coding era, this gets worse.

AI increases the amount of product change that can happen inside a sprint. But unless test creation also becomes faster and more distributed, QA becomes the limiting factor.

Pressuring testers to work faster will not fix this.

The ownership model has to change.

Every team member should contribute to test coverage

During the sprint, every team member should contribute to automated test coverage.

That does not mean every person has to become a Selenium engineer or a Playwright expert. It means the team should treat automated coverage as part of the work, not as a separate cleanup task.

A realistic sprint model looks more like this:

Testing keeps up when the whole team contributes small pieces throughout the sprint.

It fails when everyone waits for one person to "do QA" at the end.

Why the test format matters

For the whole team to contribute to automated tests, the tests must be understandable.

This is where many code-based automation frameworks fail in practice.

A Playwright test can be clean and readable when it is written by a skilled automation engineer. But after a few months of AI-generated additions, one-off helper methods, copied selectors, random waits, fixtures, mocks, authentication shortcuts, and test data hacks, the test suite can become difficult for the average team member to understand.

At that point, the framework becomes a black box.

The team no longer knows:

• What the tests are really covering.
• Which tests are outdated.
• Which helpers are still used.
• Which locators are reliable.
• Which waits are hiding real bugs.
• Which assertions actually matter.
• Which failures are product defects and which are framework defects.

This creates a strange situation where you now need to test the tests.

That is not a good place to be.

A test format that only automation specialists can understand will usually lead to low adoption. Developers will skip running the tests. Product managers will not review them. Manual testers will avoid editing them. New team members will be afraid to touch them.

And when tests are not understood, they are not trusted.

AI-generated Playwright tests can make a bad process fail faster

Using AI tools like Claude, ChatGPT, or GitHub Copilot to generate Playwright tests can be useful.

For a demo, it can look amazing.

You paste a scenario. The AI generates a test. The browser opens. The test clicks through the application. Everyone is impressed.

For a proof of concept, that can be enough.

But a real test suite is not a demo.

A real test suite has to survive:

• UI changes.
• New authentication flows.
• Different test data states.
• Browser differences.
• Feature flags.
• Slow environments.
• Failed network calls.
• Reused components.
• Refactored pages.
• New team members.
• Hundreds or thousands of test executions.

AI-generated Playwright code can help you create tests faster, but it can also accelerate the creation of a test codebase that nobody wants to maintain.

The output is still code.

That means the team still needs to manage:

• Code review.
• Test architecture.
• Fixtures.
• Page objects.
• Selectors.
• Waits.
• Helpers.
• Data setup.
• Environment configuration.
• CI/CD failures.
• Flaky test triage.
• Refactoring.
• Documentation.

The danger is that AI makes the early part feel easy while pushing the hard part into the future.

After a few weeks, the tests become more complex. After a few months, the codebase becomes bloated. After enough AI-assisted changes, the Playwright suite may become a collection of code that nobody fully understands.

At that point, AI is helping a weak QA process fail faster.

Unit tests and component tests are not enough

Developers sometimes assume that unit tests and component tests are enough.

They are not.

Unit tests, component tests, and API tests are all important. They catch many defects early and cheaply.

But they do not prove that the product works for the user.

A unit test can confirm that a function returns the right value. A component test can confirm that a UI component renders in isolation. An API test can confirm that an endpoint returns the expected response.

But a customer does not experience your product as isolated functions, components, or API responses.

A customer experiences a complete flow:

1. They open the website.
2. They sign up.
3. They verify an email.
4. They receive an SMS code.
5. They enter payment details.
6. They upload a file.
7. They download a PDF.
8. They expect the account state to update.
9. They expect the right confirmation message.
10. They expect the same journey to work in their browser.

That is why functional end-to-end tests matter.

Research on developer testing practices also shows a persistent gap between production code and test code. One survey noted that developers often spend far more time writing production code than writing tests, and that some projects lack automatically executed tests entirely.

That gap becomes more dangerous when AI increases the amount of production code being created.

End-to-end tests validate the business flow

What makes a test end-to-end is that it validates whether the product works from the user's perspective, not its length.

That distinction matters.

A database update might prove that one technical layer worked. But it does not prove that the user successfully completed the journey.

For example, imagine a signup flow.

A backend test might confirm that a user record was created. But the real user journey includes more than that:

• Did the signup form load correctly?
• Did validation work?
• Did the user receive the confirmation email?
• Did the email link work?
• Did the SMS code arrive?
• Did the browser redirect correctly?
• Did the onboarding page display the right state?
• Did the same flow work in Safari, Firefox, Edge, and Chrome?

Seeing a field updated in the database is not enough.

The business cares whether the customer can complete the flow.

That is why automated end-to-end testing has become more important, not less important, in the AI development era.

Cross-browser testing is still required

Some teams quietly assume that browser testing is less important because "everyone uses Chrome."

That is not how real products work.

Chrome is important, but it is not the only browser that matters. Edge, Firefox, and Safari each have real users and real differences. Safari in particular can expose bugs that do not appear in Chromium-based browsers.

Cross-browser issues can appear in:

• CSS rendering.
• Date and time inputs.
• File uploads.
• Clipboard behavior.
• Media handling.
• Authentication popups.
• JavaScript APIs.
• Browser storage.
• Payment flows.
• Responsive layouts.
• PDF previews.
• Download behavior.

If a user cannot complete checkout on Safari, it does not matter that the flow passed in Chrome.

And if your tests run only in a headless Linux environment, you may miss issues that happen in real browsers on real operating systems.

A strong testing strategy should include functional end-to-end cross-browser tests for the flows that matter most.

For more detail on browser coverage strategy, see the Endtest guide on what browsers you should test your website on.

Why classic Selenium and Playwright frameworks struggle

Selenium and Playwright are powerful tools.

They can automate browsers.

The problem is that many organizations underestimate the long-term cost of owning a custom test automation framework.

A real framework requires:

• Architecture.
• Page objects or screen objects.
• Locator strategy.
• Test data strategy.
• Environment setup.
• Parallel execution.
• Browser infrastructure.
• CI/CD integration.
• Reporting.
• Screenshots and videos.
• Retry logic.
• Failure classification.
• Code review.
• Refactoring.
• Documentation.
• Onboarding.
• Ownership.

Research on Selenium usage has found common challenges around assertability, asynchrony, and brittleness. Other research into automated testing adoption lists expertise, time, cost, tools, maintenance, and organizational capacity as recurring barriers.

Those findings match what many teams experience in practice.

The first few Selenium or Playwright tests are exciting. The next 50 are manageable. The next 500 become a product of their own.

And once the framework becomes its own product, someone has to maintain that product.

The hidden cost of framework ownership

Many teams choose Selenium or Playwright because the tools are open source.

But the framework is not free.

The true cost includes:

• The people who design it.
• The people who maintain it.
• The time spent debugging flaky failures.
• The cloud infrastructure or browser grid.
• The cost of cross-browser execution.
• The cost of code review.
• The cost of onboarding new team members.
• The cost of tests that are ignored because they are not trusted.
• The cost of production defects that escaped because coverage was incomplete.

This is why "we use Playwright" is not the same as "we have a reliable test automation process."

A framework is only useful if the team can keep it current.

If only one or two people understand it, the process is fragile.

Testing must move from late validation to continuous coverage

To keep up with development, testing has to move earlier and stay active throughout the sprint.

That does not mean every end-to-end test can be written before the UI exists. In many real teams, that is not realistic.

But it does mean test coverage should evolve with the feature.

A better sprint workflow looks like this:

You do not need every test at the beginning.

The goal is to avoid leaving all testing until the end.

The role of CI/CD in modern testing

CI/CD should not be a place where tests go to die.

A healthy CI/CD testing process should be fast, trusted, and layered.

Not every test needs to run on every commit. But every important flow should run at the right time.

A practical structure is:

• Unit tests on every commit.
• API tests on every pull request.
• Critical E2E smoke tests before merge.
• Cross-browser smoke tests before release.
• Full regression tests on a schedule.
• Production monitoring tests for critical journeys.

The most important rule is that if a test is in CI/CD, the team must trust it.

If tests are flaky, outdated, or impossible to understand, people will start ignoring failures. Once that happens, the pipeline becomes noise.

A smaller trusted suite is better than a large ignored suite.

Why readable tests improve team adoption

Readable tests create shared ownership.

When tests are easy to understand, more people can participate:

• Developers can see what behavior is expected.
• QA can update tests without waiting for automation engineers.
• Product managers can confirm that important journeys are covered.
• Support teams can ask for customer issues to become regression tests.
• Engineering managers can see where delivery risk is increasing.

This is why codeless and no-code test automation can be useful when done correctly.

Creating tests without code is only part of the value.

The bigger part is that tests can be reviewed, edited, and trusted by more people.

A test suite should not be a private language understood only by its original author.

How Endtest helps testing keep up with development

Endtest is designed for teams that need automated testing to move at the same speed as development.

Instead of forcing every team to build and maintain a custom Selenium or Playwright framework, Endtest provides a no-code platform for creating, running, and maintaining end-to-end tests in the cloud.

The platform helps teams create tests with the AI Test Creation Agent, edit tests as standard readable steps, run tests on real browsers, use self-healing when locators change, and integrate automated testing into CI/CD.

That matters because the realistic way for every team member to contribute to test coverage is to keep tests in a format that is easy to understand and update, rather than making everyone write code.

Editable steps instead of black-box test code

The main difference with Endtest is that AI-generated tests become editable Endtest steps.

That is important.

If AI generates code, the team now has more code to maintain. If AI generates opaque instructions, the team cannot easily inspect or adjust the result.

Endtest gives teams a better middle ground: AI helps create the test, but the output remains readable and editable.

This helps with adoption because non-developers can understand what the test does. It also helps with maintenance because the team can update the test without digging through a codebase of fixtures, helpers, waits, and selectors.

In the AI era, that difference matters.

AI should reduce the maintenance burden, not create another black box.

Real end-to-end workflows

Endtest supports real end-to-end testing scenarios that go beyond simple UI clicks.

Teams can automate flows that include:

• Login.
• Signup.
• Email validation.
• SMS verification.
• File uploads.
• File downloads.
• PDF validation.
• API calls.
• Visual checks.
• Accessibility checks.
• Cross-browser execution.
• Scheduled runs.
• CI/CD integration.

This is what modern product testing needs.

A user journey does not stop at the browser button. It often crosses emails, SMS messages, files, APIs, and generated documents.

A testing tool that cannot handle those parts of the journey will eventually force the team back into manual checks.

Real cross-browser cloud execution

Endtest runs tests in the cloud on real browsers, including real browsers on Windows and macOS.

That is important because browser coverage should match what your customers use.

If your customers use Safari, you need confidence that your critical flows work in Safari. If your customers use Firefox or Edge, those browsers deserve coverage too.

Cross-browser testing should not require the team to build and maintain its own browser grid.

Testing keeps up with development when browser coverage becomes part of the normal workflow.

Self-healing and maintainability

UI changes are inevitable.

Buttons move. Labels change. CSS classes get renamed. Components are replaced. Forms are redesigned. Flows are refactored.

A modern test automation process has to expect that.

Endtest includes self-healing capabilities that help recover when elements change. It can use stored backup locators and AI-assisted alternatives to keep tests running when the UI changes.

But the important part is that the tests remain reviewable.

Self-healing should not secretly mutate a test suite into something nobody understands. It should help the team reduce maintenance while keeping control.

Customer stories: better delivery with fewer defects

Endtest customer stories show a consistent pattern.

Teams usually arrive with one of these problems:

• Manual regression testing cannot keep up.
• Selenium or Playwright tests became difficult to maintain.
• Cross-browser testing is inconsistent.
• QA is overloaded at the end of every sprint.
• Developers do not trust the automated tests.
• Product changes are shipping faster than test coverage.
• Important user flows are still checked manually.

After moving critical flows into Endtest, teams are able to create tests faster, maintain coverage more consistently, and reduce the number of defects that reach production.

The most important change is the operating model, more than the tool.

When tests are easier to create, understand, run, and update, more people participate in quality. QA stops being the final gate and becomes part of the sprint rhythm.

That is how testing keeps up.

A practical framework for keeping testing in sync with development

Here is a practical model teams can use.

1. Define the critical user journeys

Start with the flows that would damage the business if they broke.

Examples:

• Signup.
• Login.
• Password reset.
• Checkout.
• Payment.
• Booking.
• Search.
• File upload.
• Report generation.
• Email confirmation.
• SMS verification.
• Subscription upgrade.
• Account cancellation.

Do not start by automating everything.

Start by protecting the journeys that matter most.

2. Decide which tests belong at which layer

A healthy test strategy uses multiple layers.

The mistake is pretending unit tests are enough.

3. Automate during the sprint

Do not wait until the last day.

As soon as part of the flow is stable, start building coverage.

For example:

• Developers add unit tests while building the logic.
• QA starts drafting the end-to-end flow from acceptance criteria.
• Product confirms the expected behavior.
• Developers add stable selectors or test IDs.
• QA creates the browser-level test once the UI is usable.
• The team reviews the automated test before the story is marked done.

The goal is to avoid sprint-end automation panic.

4. Make automated coverage part of the definition of done

If a feature is important enough to build, it is usually important enough to test.

A stronger definition of done might include:

• Unit tests for new logic.
• API or integration tests where appropriate.
• End-to-end coverage for critical user-facing flows.
• Cross-browser coverage for high-risk flows.
• Updated regression tests when existing behavior changes.
• Passing CI checks.
• Test evidence attached to the ticket.

This does not mean every ticket needs a new E2E test.

It means the team should make an intentional decision instead of leaving coverage to chance.

5. Keep tests readable

Readable tests are easier to review, maintain, and trust.

If the test suite becomes a code maze, adoption drops. If the tests are clear and editable, more people can help keep them current.

That is why no-code and codeless platforms are useful for cross-functional teams. They reduce the distance between product behavior and test implementation.

6. Run the right tests at the right time

A common mistake is trying to run every test on every commit.

That can make CI slow and frustrating.

Instead, create layers:

• Fast unit and API checks on each commit.
• Critical E2E smoke tests on pull requests.
• Cross-browser smoke tests before release.
• Full regression tests nightly.
• Production monitoring tests on a schedule.

This keeps feedback fast without giving up coverage.

7. Treat test maintenance as product work

Test maintenance is not a side task.

If the product changes, the tests must change.

A team that refuses to maintain tests is really choosing to lose confidence in the product.

The better approach is to make test updates part of normal sprint work. If a story changes a flow, the story should include updating the related automated tests.

8. Use AI carefully

AI can help testing keep up with development, but only if it improves the process.

Good uses of AI in testing include:

• Creating draft test flows.
• Suggesting locators.
• Generating assertions.
• Helping with variables.
• Summarizing failures.
• Assisting with self-healing.
• Converting manual cases into automated steps.
• Explaining test failures.

Risky uses of AI include:

• Generating large amounts of test code nobody reviews.
• Creating duplicate coverage.
• Hiding test intent inside complex helpers.
• Adding waits instead of fixing synchronization.
• Treating AI output as automatically correct.
• Letting the test suite become another black box.

AI should make tests easier to understand, not harder.

Signs your testing process is falling behind

Your testing process is not keeping up with development if:

• Automated tests are often disabled in CI.
• QA is overloaded at the end of every sprint.
• Developers avoid running the full test suite.
• Product managers do not know what is covered.
• Only one person understands the framework.
• Tests fail for unclear reasons.
• Manual regression still controls release confidence.
• Browser-specific bugs reach production.
• New features ship without automated coverage.
• AI-generated test code is growing faster than the team can review it.

These are delivery problems as much as QA problems.

What a modern testing process should look like

A modern testing process should be:

• Collaborative.
• Automated.
• Understandable.
• Cross-browser.
• End-to-end.
• Integrated into CI/CD.
• Maintained during the sprint.
• Supported by AI where useful.
• Owned by the team, not one person.
• Focused on user journeys rather than only technical checks.

This is the difference between testing as a gate and testing as a feedback system.

A gate slows people down.

A feedback system helps the team move faster safely.

Final recommendation

Testing keeps up with development when it stops being treated as a final step.

AI coding tools are making development faster. That creates more code, more change, and more risk. If QA stays manual, isolated, or dependent on one automation specialist, it becomes the bottleneck.

The fix is to modernize testing, which means automated tests that are created during the sprint, understood by the whole team, maintained as the product changes, and executed across the browsers and workflows that matter.

Unit tests and component tests are necessary, but they are not enough. Functional end-to-end cross-browser tests are required to know that the product works as expected for real users.

Selenium and Playwright can be powerful, but they often become difficult to maintain when the whole team cannot understand or contribute to the framework. AI-generated Playwright code may help in a demo, but it can also create a bloated black-box test codebase if the process is weak.

Endtest helps solve this problem by giving teams a no-code platform where AI can create editable tests, real browsers can execute complete workflows, and the whole team can participate in test automation.

Testing keeps up with development when quality moves at the same speed as the product, not when developers slow down.