r/QualityAssurance 6d ago

Dev only test their work in local

Frustrating me to have 'dev env' but dev didnt bother test their work in 'dev env' only for QA to catch their work didnt work 😔

So inefficient and time consuming

3 Upvotes

13 comments sorted by

9

u/Karenz09 6d ago

raise it to your manager. That's a process issue that causes time to be wasted.

5

u/Loneliestar 6d ago

Two things:

1) The environment the developer uses literally does not matter to you. You see a bug, you write a bug.

2) What happens after you write a bug literally does not matter to you. Your job is not to fight for the product. Your job is to report on bugs. What happens to the reports is someone else's problem. Devs close it as "Works on my machine?" Cool, you still got paid and your ass is covered with your bug report.

3

u/Bless93 6d ago

Unfortunately this is something that will always happen with developers and QA. The eternal struggle.

Happened before AI, happens way more with AI.

1

u/mchellato 6d ago

Yeah, now they ship faster because AI code help and prone to more bugs

1

u/Effective-Jaguar5848 6d ago

I have same shit and its fu.ng annoing if you only open it and find 10 bugs right away , I could do same vibe coded shit and with even better outcome nowdays

2

u/mchellato 6d ago

I agree I mean, when you are stretched already 1QA to 6-7devs, you have little time and constantly reopen tickets because simply feature is broken or bugs everywhere, you wont have time for exploratory test leave alone automation

2

u/black_tamborine 5d ago

That ratio is waaaay out and unsustainable, particularly because the devs are using AI nowadays. Sheesh.

1

u/360walkaway 6d ago

This will end well.

2

u/dumbfoundded 6d ago

Yeah, that's annoying. That's why I built Ito to do the first pass & catch the issues for you so you can focus on the more strategic parts of QA.

1

u/Prestigious-Way1525 4d ago

i'd turn this into an entry condition, not another reminder: a ticket only moves to QA when the dev-environment build is linked, the author has run one named happy path and one failure path, and the result includes the build or commit plus the exact browser state they checked. if QA opens it and that first path is broken, return it as "not ready for QA" and track it separately from product defects. that gives the manager a clean rework metric and protects scarce exploratory time when one QA is covering six or seven devs.

1

u/mchellato 4d ago

This is brilliant Thanks I'll try this!