The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
LOL this is one of my favourite subjects Not just everything you've said, but the emails 30 minutes later with all of your managers CC'd in asking if there is "any progress?" Then there is "tester driven design" where rather than ensuring the ticket meets the specs, they'll raise an issue if it does something they think it shouldn't, or doesn't do something they think it should.
"I've failed this because the widget doesn't highlight when hovered over"
"I've checked the specs and the acceptance criteria, and gone over my meeting notes, and I don't see that listed as a requirement?"
"I know, I just think it should highlight when hovered over"
*30 mins later*
"ANY PROGRESS ON THE CRITICAL BUG I RAISED ABOUT THE LACK OF HOVER????"
Then there is the constant interruptions if they've found a bug. If you find a bug log it in the tracker, I don't need you to stop me from what I'm doing to show me that when you click this button with the textbox empty that you get an error. Just raise it in the tracker.
Then to cap it all off, when bugs gets missed and make it live do the testers ever get any blow-back or criticism? Nope....
I've straight up not renewed a contract as I couldn't stand the testers.
Just as it's not the tester's role to assign users or priority to bugs it's not your role to put the tester in place.
Discuss the issue with your team lead, product owner, manager or whatever you have above you and let them handle it.
In the meantime, ignore the tester and pick up bugs and stories that have been approved through the regular process.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
If you have a product owner for the project, then they should be responsible for prioritising which bugs get fixed when. They are the product stakeholders and should have the final say in a bug's priority. The testers therefore should liaise with the product owner, not the developers. Once the product owner has assigned the relevant priority to a bug, then the appropriate developer can fix it.
In the absence of a product owner, then another similar person who can represent the product or the business will be sufficient.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Some testers (QA folk) think they are project managers - and these people are a detriment to delivering a quality product on time.
Others understand their role in a team delivering a product, and work as cooperating team members, focusing on how well their tests cover the code's functionality and the user's potential input. These folks are an invaluable asset.
IMHO, on a development team, the QA person should be involved to some degree (as a non-developer) during development so they are better prepared when testing starts, but should report to the team lead, who (again, IMHO) is a senior-level software engineer with solid business, communications, and leadership knowledge, skills, and abilities.
Yes. let's quit pretending the email is a legitimate bug tracking tool.
This should be entered in whatever tool you use to track the change to begin with.
You can choose to keep the current ticket open and add to it (fewer things to track, but multiple problem reports make it confusing) or open a new ticket for each reported problem, tying it back to the original change request.
I'd argue that QA shouldn't even be assigning these things, but that might be a bit much. Probably want to have the original developer investigate any fixes.
Also, someone has to be able to shut QA down if the perceived problem is actually a new change. "I found/thought of something that's not in the requirements, it's a bug!" might not be so. If it hinders use of the tool, then yes, it should be addressed. If it's just a "nice to have", it's an enhancement for future development.