Blog Series: QA Reimagined – Navigating Agile, AI and Automation-Part 3

Part 3: Test Automation in Agile – Designed for Speed, Built for Confidence

If you missed the last post:

In Part 2, I talked about the foundational QA principles that still matter — things like layered test strategies, the role of risk, and how quality must be a team mindset. That post grounded us.

This one builds forward.

We All Have Tests — But Do We Have a Test Strategy?

Let’s face it: almost every modern Agile team has some form of test automation in place. Whether it’s unit tests run through CI, API checks on a staging environment, or a bunch of end-to-end tests trying to simulate real-world scenarios — we’ve all got something running somewhere.

But the real question I keep asking is this:

Is our test automation actually serving the pace and priorities of our team — or are we just dragging legacy habits into faster cycles?

Over the years, I’ve seen this pattern repeat across teams of all sizes:

Test suites grow, but feedback slows. CI pipelines exist, but no one fully trusts them. Automation exists… but it doesn’t accelerate delivery — it delays it.

It doesn’t have to be that way.

Agile Changed Everything — Automation Has to Catch Up

In Agile, the way we build software has changed dramatically:

Stories are smaller and continuously evolving. Releases can happen daily — or multiple times a day. Feedback loops are expected to be instant.

So automation has to shift from being a standalone initiative to becoming a core enabler of flow.

This means:

Writing tests in the sprint, not after. Testing small, frequent changes — not large, delayed bundles. Designing automation with feedback and trust in mind — not just pass/fail results.

In Agile, test automation isn’t a phase. It’s an embedded feedback system.

Automation That Supports the Flow of Agile Work

Here’s what’s working well in teams I’ve supported or worked with:

1. Automation aligned to story delivery

Test cases are created with the story. That might mean:

Developers and QA pairing on both unit and functional tests Feature-flag-aware tests for toggled or incomplete features

2. Pipelines that prioritize speed and confidence

A typical setup might look like:

Fast unit tests on every commit

Selected integration/API tests based on change impact

Targeted E2E tests on merge or before deployment Full regression in nightly runs, not every PR

We stop expecting every test to run everywhere — and start thinking about purpose and signal-to-noise ratio.

3. Failures lead to learning, not just red pipelines

Flaky tests are tracked and reviewed regularly. Test ownership is clear. When a test fails, we don’t ignore it — we ask, “Is this still valid? What is it telling us?”

Automation Is More Than Writing Scripts

One mindset shift I always encourage is this:

Automation is not just about writing Selenium, Cypress, or Playwright scripts. It’s about designing systems for feedback, trust, and maintainability.

Ask yourself:

Are tests reliable enough to gate a release?

Can you pinpoint which change broke what — or does it require detective work?

Do devs want to run the tests before merging — or do they avoid them?

If your automation adds friction instead of flow, it’s time to rethink its design — not just its tool.

Common Pitfalls I Still See:

Let’s be honest — these still happen too often:

-End-to-End Overload: Too many UI tests trying to cover business logic.

-Unowned Test Suites: No one tracks failures, test coverage, or test debt.

-“Automate Everything” Pressure: No prioritization, leading to bloat and slow pipelines.

-Test-After Stories: Dev work is marked “done,” and test work begins from scratch.

Agile isn’t just about speed. It’s about delivering value faster. Automation has to support that mission.

When working with teams, here are the core principles I lean on and truly advocate for. Fair enough in my experiences with those teams, we might not have achieved all of this, but I always believe in the North Star and vision, and thus geared the teams to start thinking in this direction. Some moved faster and others slower (based on the situation in every org/team). Nonetheless I will still encourage everyone to start thinking along these lines:

-Automate by intent, not inertia. Every test should have a reason to exist.

-Time-box test coverage per sprint. If it doesn’t make the sprint, it needs to be tracked and prioritized.

-Use tags or annotations. Not all tests need to run on every pipeline. Design for filtering.

-Maintain a quality dashboard. Track flakiness, failure reasons, execution time, and trust levels.

-Review tests in retros. What passed? What failed? Why? Are we testing too much or not enough?

Closing Thoughts: Automation That Serves, Not Slows

Automation is powerful — but only if it serves the team.

If your tests aren’t giving your team confidence, clarity, and speed, then they’re just noise. Agile requires us to move fast, yes — but not blindly.

The best automation strategy is one that your team trusts and uses — every day.

Stay tuned to the next blog post, it’s about to get a little more technical from this point on, so stay tuned for more…