so the new QA guy just raised 8 new tickets all of which are UI related

full stop is missing
buttons are slightly misaligned
need to add a space in between
etc

all these things can be fixed over a 5 minute call, but noooo he took screenshots, created report, created 8 separate jira tickets with the steps to reproduce and attached screenshots and sent the testing report to all the managers

is this normal in big companies? i feel like it's grossly inefficient and unnecessary

I work in a 20 person startup, the previous qa guy used to call me up directly and explains the issues, he only creates tickets for the things which couldn't be fixed in an hour, I usually fix most those things in under an hour and he provides sign off

If one finds multiple minor issues, I would expect them to create a single ticket.

But otherwise: No ticket, no work.

It's to log the development work, and to know the shit quality they did by linking the parent task, that dev better step up his game and do things correctly

It’s normal in my company to have a separate ticket per issue for the same project. Perhaps the QA team assumes you don’t have time for calls, which will likely become the case as your company and work load grows. It’s annoying to tackle multiple tickets BUT it is nice to have your work documented somewhere. It comes in handy when you have to switch tasks/projects or need receipts for future issues/proof of work.

The sending it out to all the higher ups part was a bit of a dick move, however. UNLESS the project is collaborative and they too had a hand in it.

Especially the part of sending it out to all managers was a shitty thing, if there is a ticketing system and they need to know, the system will tell them.

That part is most likely just trying to prove his worth by showing of he found things.

But the actual documentation in tickets, sure, if you work really tightly and know things will get fixed during a call you can do that but at my work, the devs are most likely working on some other task by the time QA finds things and its up to the scrum master and project owner to decide if the problems should be fixed now or later.

Maybe there are more things to be changed for that UI in the next sprint so doing it together is more effective.

Especially if your working with branches.

But I assume in a startup environment you can expedite things by just taking it as you go.

My closest experience was when we at my former work started with web applications, we did things much like your used to, but we also was just two devs and one qa/project owner ;)

And we did not even have a ticketing system.

Its normal, especially in service company. Take a coffee, embrace inefficiency of large company. Fix the tickets in 2 days and complain how much work you have. This helps You blend in

@Avimelekh the new qa guy comes from a service based company
if we do it his way, probably we'll close our offices down in 6 months

startups need to be efficient, we are already short staffed

Well i think you guys messed up during recruiting. Anyhow from his perspective he is doing things as he knows they should be done. Best you can do is to agree common rules everybody understands, not agrees upon but understands, at the moment problem isnt really that any of you does anything bad to another, just not understanding eachother, and latter can only be solved with communication of expectations and working out common rules of work. Im fairly sure if you explain your qa what you expect from him/her he will try to meet you half way

Don't see the problem here. This is how ticketing is supposed to work.

Yes, it's normal to create tickets even for small issues. I've seen too many companies with the "it's just a small fix, I can just quickly do that on the master"-mentality (or similar quick solutions) and it always blows up in your face sooner or later.

The messaging all the managers part however seems more of a way to make themselves feel valuable. Depends on the managers whether they realize those issues were not worth being emailed over, some will see that immediately, some are not that smart.