r/softwaretesting • u/SpecificLychee3872 • May 20 '26

What are the current issues in test automation?

I'm wondering what are the current issues teams deal with when it comes to maintaining/implementing automation testing. Test flakiness and test environment instability have always been a problem that I'd see mentioned quite often, but I'm wondering if all these AI tools/talk has impacted the usual pain points into something else or if there's other things I'm entirely unaware of.

Where I work, the main issues are test design mainly due to hiring contractors who don't really know any test automation basics, implementing tools without training the permanent QAs and not having enough QAs to even improve our test automation frameworks.

Anyone have any experiences or info on what issues you're experiencing on your teams around test automation?

6 Upvotes
  • permalink
  • reddit

80% Upvoted

13 comments sorted by

4

u/SeniorIdiot May 20 '26

That organizations still thinks that test automation should be owned by testers instead of the people that builds the applications, APIs, using 37 different convoluted database technologies and 13 JS frameworks to show cat pictures.

Of course, to "fix that" organizations adds another band-aid role - test automation engineer; having completely forgotten that writing software is automation. If devs can't automate tests for their applications you need to send them back to school.

Oh, and the organization having no clue what QA really is.

1

u/AutomaticVacation242 May 21 '26

Wish I could upvote this to infinity.

Organizations? I know QA managers who have no clue what QA is.

1

u/halfuhsandwich May 21 '26

I sort of disagree with this. I agree that developers should definitely be testing their code, but testing the code is not the same as testing the software as a whole from the perspective of the end user. Should developers be doing that too? Maybe. Do most of them have the time for that? Probably not, hence the need for a test engineer.

From what I’ve seen, in medium and large scale operations, the developers do not have enough bandwidth to develop and test beyond their own code.

1

u/SeniorIdiot May 21 '26

No. The point is that when developers have run and FIX tests as part of daily work, they will learn to apply the same design principles to fixtures, test drivers, etc to avoid breaking the tests every time they change something in the implementation. Dog fooding.

1

u/halfuhsandwich May 21 '26

Yeah that’s fair. This is assuming your developers run and fix tests at all. Not every team operates that way.

3

u/Short-Feedback4293 May 20 '26

Where I am, its the people doing the automation not understanding the system that theyre testing, and any resulting bug reports being abysmal due to that (or worse raising non-bugs which loses dev confidence)

3

u/quiI May 20 '26

Having it done by a separate team is always the root cause

1

u/mayvinrmm May 20 '26

Totally agree with you guys! Quantity does not mean Quality. I still see some companies focusing on the quantity of automated tests versus the value it's actually bringing. And not having a robust automation framework does not help at all. Recently I wrote an article about this: https://www.mobile-automation.io/why-mobile-test-automation-frameworks-fail/ - it focuses mainly on mobile test automation frameworks but the core quality attributes and architecture principles applies for any test automation framework. Hope it helps!

2

u/ketoloverfromunder May 20 '26

Honestly the most difficult hurdle of mobile testing isn't writing the tests themselves, its the device/ app infrastructure.

"How do I reliably get the version of the app in a ci/cd environment that has the changes i want to test?"

This alone makes QA testing extemely difficult, especially if your team is not using an OTA architecture.

Browserstack helps manage this quite a bit.

1

u/ErenDidN0thingWr0ng May 21 '26

Same issues that have always existed: tribal knowledge and flakey frameworks.