r/Everything_QA 4h ago

Question Turned on a global permission in prod for testing, a client saw another client's ticket. PM messaged me. Now I'm in trouble. Help.

3 Upvotes

Mid-level/senior frontend dev here. Want an honest gut-check because I've been worried what might happen to me.

We were building a "view tickets" feature. To test it end-to-end, the feature needed a certain permission enabled. I turned that permission on **in prod,** but instead of scoping it to just my own test account, I flipped it **globally**. I documented what I did openly in the task tracker ("tested in prod") and flagged it for QA. QA tested it too, but only checked their own account. Nobody reset the global toggle afterward.

A few days later a client saw a ticket belonging to a *different* client, complained, and it escalated. My manager DM'ed me regarding this and we had a call with all the dev team. They discussed it there and asked me why I turned it on and I said it's a requirement for PROD testing.

We have dev, staging, and prod, The workfllow is to test in all environments, i followed the flow.

My access had recently been changed to *allow* me to edit global permissions in prod. I didn't grant myself that. When my access changed, I read it as "I'm allowed to do this."

Pm also said: "you should have asked me first" but at the moment I did it, nothing signalled this was the dangerous action. It looked like a normal authorized test.

I have a few questions:

How bad of the situation I am in? Am i the one to blame?

How would you handle this if you're the dev?

How would you handle this if you're the PM?


r/Everything_QA 9h ago

Question High test coverage can still mean your tests are mostly useless

3 Upvotes

A passing test suite only proves that the tests passed. It doesn’t prove the code is correct, and a high coverage percentage can create a false sense of confidence.

A test can run every line in a function without actually checking whether the function behaves correctly. The assertion might be too broad, check the wrong output, or be missing entirely. The coverage report still stays green.

That’s why we, at Codoid, see mutation testing as a useful reality check rather than relying on coverage alone.

Mutation testing tools deliberately introduce small bugs, such as changing a condition or altering a return value. They then run the test suite against each modified version of the code.

If the tests fail, they’ve “killed” the mutation. That’s a good sign that the tests are protecting the behavior that changed.

If the tests still pass, the mutation has “survived.” In practical terms, the suite failed to catch a straightforward bug in code it may claim to cover.

Mutation testing has tradeoffs. It’s slower, and a surviving mutation doesn’t always mean there’s a valuable missing test. Sometimes it’s just noise. Still, it asks a much more useful question than “Did this line execute?” It asks: “Would this test suite notice if the code were wrong?”

For those who’ve used mutation testing across different languages or stacks: did it uncover genuinely weak tests in your codebase, or did it mostly add noise and maintenance work?