Testing Bull$hit Bingo

Hey all,

I’m collecting “statements” for a “Testing Bull$hit Bingo”.

Things like “It’s so easy, we don’t need to test it”, “No user would ever do that”, “This is an edge case” and so on… I think you get the idea.

Please reply with your favourite bull$hit phrases, thanks a lot!

7 Likes

“I only changed one line of code” ← Yeah, but that line of code governed permissions to the entire application and the missing “not” meant nobody had the permissions they should have.

“It’s only cosmetic” ← and if it doesn’t look right users are going to think we don’t care about the big stuff

“It’s fully unit tested” ← and? Is it also fully integration tested? Does it do what the customer wants?

“The UI makes it obvious what to do.” ← No it doesn’t. It makes it obvious for users like you, who are a minority out there in the non-technical world.

And yes, I’ve run into all of these as well as @christianbaumann’s starting list during my career.

(As a side note: I’ve generally found that cases of “No user would ever do that” are proved false within days, sometimes hours, of said users receiving the software - and I’ve refuted a few of them with the response “I did. What’s to stop someone else?”.)

5 Likes
  • “Works on my machine”
  • Blames user (this has many variants)
  • “The developer is senior so there are no bugs”
  • “That is not a technical profile” (referring to a tester that doesn’t code, infuriating)
6 Likes

Similar to @thepoplipo 's last entry,
A developer to a tester: “This is too technical, you wouldn’t understand”

3 Likes

Adding to @katepaulk & @thepoplipo lists:

  • “This is a known issue.”
  • “It’s not a high-priority issue, we can go live with it.”
  • “We’ll fix this in next sprint.”
  • “Issue is only on older alien versions, we won’t fix it.” (even though issue is on few versions back, dev said this many times)
  • “It may be caching.” (tells after dev fixed the issue every time)
4 Likes

Some I’ve heard:

  • Unit tests are green
  • I modified the test to pass (they were failing because of a bug, the dev didn’t fix the bug, just made the test pass…)
  • We can’t test the change in the backend because the UI is not ready (tester’s in backend teams who don’t know how to use postman or any other api testing tool…)
  • Or the opposite " We can’t test the UI change because the backend is not ready" , saying this while they have a framework set up to be able to mock the backend to test the UI changes
4 Likes

Nearly all of the above and:

  • “Why was this not found during testing?”
  • “It’s just an internal bug.” (apparently it’s better for things to be found in production by the customer, but also see point above)
  • “This can’t be tested.” (might require some thinking on dev side to figure out how)
  • “We turned the tests off, because they were failing.” (so we don’t actually have unit test coverage)
  • “It’s too late to add unit tests.” (but somehow not too late for testers to add other automation)
  • “Can you create a ticket for that?” (report you own findings, testers are not secretaries for dev)
  • “That only happens because of automation.” (bugs found through automation are somehow all the fault of the automation setup and environment)
  • “Why is testing taking so long?” (sorry it’s taking us a month or two to check what was developed during hat last year)
  • “You can create a ticket for that, but we are never going to fix it.” (how about we document that)
  • “Things were better when X was testing.” (I wonder why they left)

Don’t know if all of these work as general points for a tester bullshit bingo game, but I definitely get bingo quite often with them.

4 Likes

Boy howdy does all of this bring back some memories.

My most recent gig there was a frequent round of:

“Its just a one line change” (I fought for extensive testing. was overruled. minor chaos in production ensues. I presented it as a case study that was really just an elaborate “I told you so” nevertheless detailing how small, untested change resulted in $$$ of developer and devops work in front of users…well lets say there was an effect on how testing was evaluated)

“Oh thats just a hostile user scenario” (MSH’s Law “All users are hostile users. If they can do it, they will” Again I presented cases where a defect report was dismissed as “hostile” and yet that very defect was reported by users/support in production)

and yeah. Im bragging. But hey, no one else is going to do it for me…

5 Likes

Developer Test Lead, “You’ll only be writing up Sev 3’s and 4’s, we have so many of them, its almost pointless to document…” - Same Test Lead then goes on to investigate and mark as a Sev 2.

4 Likes

everything should work as before :blush:

3 Likes

“It depends on the context.”

Placed here with no further comments. :zipper_mouth_face:

3 Likes
  • “transiting from manual to automated testing”
  • ISTQB
2 Likes
  • Why QA not found this issue earlier, Who test this ticket ?
  • We’ll fix this later
  • Small code change take >= 2 week test regression. small code change as hotfix → straight to production
  • Let’s Automated QA write automation this case later.
  • “Just test and make sure everything working fine” (with 5k line of code changed and no explanation)
4 Likes

hello @christianbaumann :wave: I have so many phrases but adding some of my favourites-

:smiling_face_with_tear:Just push it to PRODUCTION, we’ll fix the bugs later.

:scream:Code is perfect and unit-testing is done, we are on a tight deadline, testing is just for formality.

:angry:This is Low priority, we dont need to test it thoroughly.

:persevere:It’s a minor glitch, user wont ever notice.

:japanese_ogre:We will call it a known issue, and take it to the second phase/release.

:sob:We dont need to test on that browser, no one uses it anyway.

3 Likes

Sometimes I jsut say : “Can I get that on tape?”, while simultaneously whipping my phone out of my pocket and pretending to tap record.

5 Likes

I can’t entirely agree that this stuff is BS :sweat_smile: There are always two sides to a coin, and it really depends on the context. As a QA engineer, tester, and
QA advocate in a way :slightly_smiling_face: I have found myself in situations where the things mentioned in the conversation didn’t sound like BS, and I have also said some of those things to my dev and QA team members. However, I do understand why many people consider it to be BS in many cases. I have been there too :sweat_smile:

5 Likes

nice one LOL sounds like real BS :smiley:

2 Likes

Just to be clear: I don’t judge the people doing this.
Both may help getting people wages.
Sadly there is demand for it and a big lack of education on the tester side as well as on the managers.

2 Likes