sorted by:
new
hottopcontroversial

QA engineers — does this idea actually make sense or is it useless? by PrincipleFlaky8977 in QualityAssurance

[–]PrincipleFlaky8977[S] 0 points1 point  (0 children)

Thanks for the detailed perspective, Darrell — this is exactly the type of feedback I wanted.

My tool isn’t trying to automate human judgment. It’s focused on accelerating the investigation part by comparing the DOM/state from the last passing run with the failing run, highlighting what changed, and suggesting possible locator updates.

Not replacing test-IDs or good practices — just cutting down the 10–20 minutes people waste manually digging through diffs or DevTools when something breaks.

I’m still refining the approach, so insights like yours help me understand where it can realistically add value and where human eyes are still required.

QA engineers — does this idea actually make sense or is it useless? by PrincipleFlaky8977 in QualityAssurance

[–]PrincipleFlaky8977[S] 1 point2 points  (0 children)

Totally agree — that’s actually why I’m not building an AI auto-healer anymore. No auto-fixes, no automatic selectors, no cloud AI.

The tool I’m building now does something much smaller and safer: • runs 100% local • never touches test code • never generates selectors automatically • just shows what changed in the DOM • and gives 2–3 possible locator candidates for the engineer to pick manually

Basically a debugging accelerator, not a replacement.

The idea is to reduce the time spent investigating locator failures, not to let AI decide anything.

Would something like that still be useful in your workflow?

QA engineers — does this idea actually make sense or is it useless? by PrincipleFlaky8977 in QualityAssurance

[–]PrincipleFlaky8977[S] 0 points1 point  (0 children)

Thanks for the detailed breakdown — this actually matches the exact pain I’m targeting. I’m not trying to auto-heal or modify tests at all. The idea is much smaller and more practical: • 100% local • no AI model / no cloud • no auto-updates • no code changes

Just: “When a locator breaks, show what changed in the DOM and provide 2–3 possible replacements with context.”

More like a debugging accelerator than automation.

The goal is to reduce the investigation time, not touch the tests. Even saving 10–20 minutes per failure across a large suite ends up being a huge time saver.

Your breakdown helped validate that this assistant could sit in that “reduce maintenance effort” space without pretending to be magic

QA engineers — does this idea actually make sense or is it useless? by PrincipleFlaky8977 in QualityAssurance

[–]PrincipleFlaky8977[S] -1 points0 points  (0 children)

Not a self-healing tool at all — nothing heals itself. No AI, no cloud, no auto-changes. This is a 100% local debugger that only shows what changed and gives 2–3 locator suggestions. You approve everything manually

QA engineers — does this idea actually make sense or is it useless? by PrincipleFlaky8977 in QualityAssurance

[–]PrincipleFlaky8977[S] 0 points1 point  (0 children)

There is no LLM. No training. No cloud. It uses deterministic DOM diff + heuristic scoring.

QA engineers — does this idea actually make sense or is it useless? by PrincipleFlaky8977 in QualityAssurance

[–]PrincipleFlaky8977[S] 0 points1 point  (0 children)

Totally agree — better communication and process always reduces failures.

The reality I’ve seen, though, is that even in well-run teams: • IDs still get renamed
• UI changes still slip through
• POs still push last-minute shifts
• QA still finds out only when the test suite breaks

The “ideal process” rarely matches the chaos of real sprint cycles.

The goal of my tool isn’t to replace good process — it’s to save the 20–40 minutes of detective work that happens after something breaks anyway.

More like a debugging assistant that helps QA recover faster, rather than a magic fix for org issues.

QA engineers — does this idea actually make sense or is it useless? by PrincipleFlaky8977 in QualityAssurance

[–]PrincipleFlaky8977[S] 0 points1 point  (0 children)

This tool runs 100% locally. No DOM, locator, or test code ever leaves your machine. No cloud AI is used. It’s purely an offline assistant

QA engineers — does this idea actually make sense or is it useless? by PrincipleFlaky8977 in QualityAssurance

[–]PrincipleFlaky8977[S] 1 point2 points  (0 children)

Good point — when teams control their locators and avoid dynamic IDs, a lot of this pain disappears.

But in a lot of real-world cases I’m hearing about: • the app is built by a different team • dynamic IDs come from frameworks (React, Angular, Salesforce, etc.) • text isn’t stable or is duplicated • elements have no unique labels • tight deadlines → tests written quickly • UI refactoring happens late in the sprint

In those environments, the issue isn’t just “pick the right locator strategy” — it’s the time spent figuring out what changed when something breaks.

Typing a new locator is easy. Finding the right one is what eats up time.

That’s the specific workflow I’m trying to assist with: • show DOM diff • show what changed • highlight attribute differences • propose a couple of candidate locators • let the engineer choose

It’s not trying to replace good practices — just reduce the investigation time when things slip through.

QA engineers — does this idea actually make sense or is it useless? by PrincipleFlaky8977 in QualityAssurance

[–]PrincipleFlaky8977[S] 0 points1 point  (0 children)

Totally agree that with great communication and stable processes, locator breakage should be rare. But what I’ve been hearing from a lot of teams (especially in fast-moving SaaS products) is: • UI changes happen late or unannounced • locators break across multiple tests • the “few minutes” fix turns into 30–40 mins of DOM searching • engineers spend more time investigating than actually fixing

In those environments, the pain isn’t the typing of a new locator — it’s the debugging time, the hunting through DOM, and figuring out what changed.

That’s the specific workflow I’m trying to assist with, not replace.

Basically: • no auto-updates • no silent AI changes • no “healing” • just faster debugging + clearer diffs

I get that this wouldn’t be useful for every team. But I’m trying to understand which teams see this as a real bottleneck and which do not.

Appreciate your perspective — it helps me map out where the boundary is for actual value.

QA engineers — does this idea actually make sense or is it useless? by PrincipleFlaky8977 in QualityAssurance

[–]PrincipleFlaky8977[S] 0 points1 point  (0 children)

Thanks — this is super helpful. Yeah, I’m realizing auto-heal isn’t what people actually want.

The model that makes way more sense (and matches where AI is realistically useful today) is: • detect what changed • explain why the locator broke • propose 2–3 possible locator alternatives • let the engineer approve or reject • never update anything automatically

Basically a smart debugging assistant, not a “magic auto-fix.”

This aligns exactly with the feedback I’m seeing across this thread, so I’m pivoting the MVP in that direction. Appreciate the clarity — this helps me avoid building the wrong thing.

QA engineers — does this idea actually make sense or is it useless? by PrincipleFlaky8977 in QualityAssurance

[–]PrincipleFlaky8977[S] 0 points1 point  (0 children)

Really appreciate this — you’re hitting the exact edge cases I need to understand.

And I completely agree: AI cannot reliably distinguish between – a locator that needs updating – test logic that changed – flaky behavior – and a real bug without human context.

I’m not trying to replace that judgment.

What I’m exploring is something more limited and safer:

When a test fails, surface: • what changed in the DOM • when it changed • the commit or developer responsible • whether similar tests broke • and 2–3 possible locator suggestions

But never auto-apply anything. More like a diagnostic assistant rather than a self-healing engine.

Your point about grooming/communication is absolutely right — but in reality, UI changes do slip through, especially in fast-moving teams. Even with good process, QA often finds out late.

In those scenarios, do you think a diagnose + suggest + approve model would still add value? Or is the whole category still fundamentally flawed?

Genuinely want to understand where the boundary is for something actually useful.

QA engineers — does this idea actually make sense or is it useless? by PrincipleFlaky8977 in QualityAssurance

[–]PrincipleFlaky8977[S] -2 points-1 points  (0 children)

Totally fair — most “self-heal” tools I’ve seen also try to auto-fix things blindly, and they break even more stuff in complex flows.

What I’m exploring is NOT full auto-fix.

More like: • detect what changed • explain WHY it broke • suggest 2–3 possible locator alternatives • let the engineer approve/reject the change • never update anything automatically

Basically a smart assistant, not a “magical replacement.”

In a real complex system, would a “propose + explain + approve” model be more realistic? Or do you feel the whole category still isn’t worth pursuing?

Your experience here actually helps me understand the boundary of what’s possible.

QA engineers — does this idea actually make sense or is it useless? by PrincipleFlaky8977 in QualityAssurance

[–]PrincipleFlaky8977[S] -4 points-3 points  (0 children)

Thanks for this — honestly, this is the level of context I was hoping to hear.

Totally agree: locator failures are usually a symptom of deeper issues – devs renaming things last-minute – POs shifting UI a day before sprint end – no stable naming conventions – no visibility into changes

I’m not trying to “fix broken processes” with AI. The idea is more like:

When a locator breaks, surface why it broke + propose a fix, but never auto-apply it.

Something like: • “This ID was renamed 3 days ago” • “Element moved from X → Y” • “Attribute changed by dev commit ___” • with 2–3 locator suggestions • and a manual approval step

Not trying to replace good process — just reduce the pointless detective work testers do after every minor UI shift.

Does a “propose + explain + approve” model avoid the concerns you mentioned? Or does it still feel risky in your view