10

So what's up with some devs, QAs and managers that create bug tickets with little to no information on what is the actual bug? I can semi-understand in the case where you document it only for you to read later.

Fuck you if you think that a ticket with only a title saying "fix all the bugs for this release" or "this feature is not working" is an appropriate way of documenting a bug.

Fuck you even more if when you are being asked to provide more info to reproduce the issue so someone else can actually be sure it is fixed or not (environment, steps, expected result, actual result, etc.), you simply say that you don't have the time for it and documenting tickets is a waste of time.

Hiring YOU was a waste of time!

Comments
  • 4
    Easy - "Closed - Can not repro because submitter was too lazy to provide steps."
  • 3
    I don't get why QA makes things so hard for themselves. I was QA and I always included screenshots, step by step directions and eventually an actual video clip of the issue so developers could see the issue because sometimes they just couldn't follow a step by step process.
  • 2
    @intoleRANT I am QA (SDET) former embedded dev.

    I guess it's just the general lack of understanding towards the importance of testing, automation and iterative validation that cause these sorts of issues.

    When I was a dev, I hated the fact that many people considered testing as a second hand type of engineering and just openly shat on it.
  • 2
    @PepeTheFrog yes, that was exactly my feeling too. It felt like there was hostilities between dev and QA but we were both on the same team. No one really told me how important testing was, but I assumed I'd I found a bug the devs might want to know how to reproduce it. But that could just be because I'd already learned how finicky computers are and that maybe my hardware was the issue, not their code.
Add Comment