AI Impact on SDLC

Discussions
, ,
1

Anyone else struggling with how to shift your QA teams process with DEV going warp speed with AI?

We are struggling to figure this out as we move to smaller micro teams. The idea being thrown around is DEVs can now create the automation. But how do we prevent test bloat and also keep QA validation without becoming a bigger bottle neck?

Does QA shift more towards AI generated test plans which provide boundaries for dev test creation? And how do we track all of this so we know AC is covered and can ship woth confidence. The days of QA Engineers writing all the automation seems to be going away. But DEV dont understand how things should be tested and we may be creating a situation where DEV just tosses crap tests over the wall with expectations QA goes faster and checks less now.

I think this is an interesting topic we are all trying to figure out. Would love others input.

2

This is a big topic, but I would be cautious about moving too much test ownership to devs just because AI makes automation easier.

My current view is that devs should mostly own unit tests. For integration, E2E, regression, and release confidence, I would still want QA to own both the strategy and the test code.

What I would like QA to be able to do is automate UI operations and use those flows for API regression testing. In many web apps, the important API behavior is exercised through real user workflows, so the UI flow is a good starting point.

But in practice there are still gaps:

  • deterministic UI execution is hard
  • QA often lacks tooling to record the API traffic behind the flow
  • even if traffic is recorded, teams still need a way to compare responses against a trusted baseline
  • the final output should be a release signal, not just “the script passed”

So I don’t think the answer is “devs generate more automation.” The harder problem is giving QA the ability to turn important user workflows into repeatable regression checks and useful release evidence.

AI can help increase capacity, but QA still needs to own the quality bar.

3

Yeah its hard to know where we should go with AI. Because on one hand I think as long as QA drives testing there is a good use case for DEVs using AI automation to create the scripts to test earlier. We just need to set boundaries.

4

There will not be one solution for this and I suspect the same named roles will have even more differences going forward than the current vastness.

One area that has stalled some of my thinking around this is that there is starting to come out stats that quality is dropping due to the use of AI even in teams that had very good quality engineering practices before AI. This counters the basic argument AI amplifies both good and bad practices.

Faro 2026 AI report

That sort of leads me away from full on agentic with one or two orchestrators with build and risk/test QE skillsets. Just because we can does not mean we should particularly if quality is getting exchanged for speed and efficiency.

I did see one proposal for three amigos extreme development style. Small team, smallish features but working real time together with AI. Worth a trial but for me there needs to be a balance for solo concentrated work.

Developers absorbing all automation with agentic usage. I like this one personally, if it was not for the quality drop risk this is the one that makes sense to me, automate alongside code has efficiency gains and already many teams do this.

The other part of why I like this one is it seems a great match for my favorite testing model of the Test Jumper that James Bach wrote about in 2014, it preserved the testing craft of discovery and learning focused testing when it was being diminished by there are no roles concepts in agile. This can support multiple projects at onces, being highly efficient the warp speed is less of a concern and it specifically counters the bug risk increase of AI in general.

If the automation is complex enough it likely still merits non-developer coverage, I’d like to think the test jumper still had a place in this model but often in smaller teams someone is going to say the economics of two risk/test type roles in smaller teams is not justified, as a result this is high risk of increased bugs and diminished test skill in my view. However many teams already have that risk from before.

I would also expect it is now easier for testers to be doing deep root cause analysis and actual fairly safe bug fixes with AI assistance, local builds and code access. It has efficiency benefits and less handovers than now whilst also might offset some activities going back to developers with also more coming to testers.

I sort of kept QE as a role out of this, we clearly need strong QE in all scenario’s but I’m not convinced that is a separate role but I can see it as dual role perhaps.

All of these are valid models in my view, there is no one best model and there are new tools and info every day. If a role though is eliminated and a month later its a nightmare its going to be hard to reverse.

5

Thanks for posting this @almiller9 , its a very pertinent subject.

This is something definitely happening in my organisation and I’m constantly communicating the risks to engineering and the wider business. We have senior leadership telling us we should be using more AI, and we are being encouraged to experiment with it and find those gains. However, there is no strategy so its turned AI adoption into an individual sport creating winners and losers.

What we’ve got right now is a lop sided engineering team in performance. The winners are more cautious are finding gains in specific things but maintaining control and ownership of their outcome. The losers are using it as their development tool for everything, something fails, its back to AI engine to find out why it got it wrong and tell it to fix it.

AI will accelerate and amplify good practice, but also bad practice. So the winners have become more productive but this productivity creates a delay/backlog elsewhere. How the organisation responds to that is crucial. Do they, work together to establish how we can join up the benefits or do they point at the affected areas and say “you need to catch up on AI”. The losers, just become less productive, they relate productivity as a quantative analysis of how much code they’ve changed, yet outcomes have dried up.

The solution is engineering teams need to not see themselves as separate teams, but all engineers with specialisms. There needs to be an organisational direction established and if you can’t get one, engineering as a whole need to start that conversation by taking ownership and making their own. That’s what I’m trying to influence, as a advocate for reducing risk to our outcomes.

6

Interesting discussion.

In my experience, AI is accelerating test creation, but it is not reducing the need for QA validation. The challenge is no longer generating tests; it is determining whether the right business risks are being covered.

I’ve found that QA adds the most value when focusing on risk assessment, workflow validation, business context, exploratory testing, and release confidence rather than simply owning automation creation.

Developers can certainly create more tests with AI assistance, but someone still needs to evaluate coverage quality, identify critical business scenarios, and investigate unexpected behavior across connected workflows.

For me, the role of QA is evolving from test execution toward validation intelligence and quality risk management.

7

The devs open to write the tests but a QA review should be possible and mandatory.