|
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.
Unless, of course, the tester is in fact your CEO 
|
|
|
|
|
Quote: 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.
hehe I'm the Lead, both the testers & devs reporting to me.
|
|
|
|
|
Then YOU should know whether the tester is out of line and if you think he is YOU should be the one to do something about it! 
|
|
|
|
|
Sounds like you are not doing your job then. As Sander it is up to you to lead your teams, you are the one who needs to assign priorities.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
That tester needs to be tied up and gagged !
|
|
|
|
|
And then tickled with a feather
|
|
|
|
|
Jörgen Andersson wrote: And then tickled with a featherchainsaw
FTFY
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?
--Zachris Topelius
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
|
|
|
|
|
Nand32 wrote: These are critical bugs fix it ASAP
This sounds like my users/testers! To them everything is critical. 
"Go forth into the source" - Neal Morse
|
|
|
|
|
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
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I think a tester isn't in the position to issue commands. A tester has to deliver information with the project lead being the one issuing commands in response to the information.
|
|
|
|
|
My 2 cents.
All "bugs" are issues.
Not all "issues" are bugs.
A bug being something of unintended outcome.
Unless the tester is viewing the innerds of the program, I would find it difficult to assert that an issue is a bug.
Raise issue, let the issue process assign priority and severity.
|
|
|
|
|
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.
|
|
|
|
|
Sounds lik a resounding reason to thoroughly test one's own code!
CQ de W5ALT
Walt Fair, Jr.PhD P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
I had a similar situation back in the 90's with a fairly senior tester. He would report bugs like this, but he would also not provide any clear way to reproduce the issue. I would get this problem report, try and reproduce it and find it all working.
So I would kick it back to him as "no repro" and ask for the steps to reproduce. Instead I just got vitriol and the bug punted back to me to fix.
In these sort of cases, it is up to management to provide a clear mechanism to decide on issues and priorities. Nowadays we tend to have sprints where the tasks are decided, including features and issues to be addressed. Only real show-stoppers can get added mid-sprint, and that still has to go through some sort of review.
To all the people in QA (I used to be one): Issues need to be investigated. Reduced to the smallest common repro steps. And any insights as to the issue is helpful. The more info you can provide, the easier you make it for development to figure out what is wrong and address it.
|
|
|
|
|
A horse walks into a bar and orders a pint.
The barkeep says "You're here pretty often. Do you think you might be an alcoholic?"
The horse replies, "I don't think I am," and vanishes from existence.
See, the joke is about Descartes' famous philosophy of 'I think, therefore, I am', but to explain that part before the rest of the joke would be putting Descartes before the horse.
|
|
|
|
|
Urm, Boom-Tish?
|
|
|
|
|
|
I tried the Drums once and was told 'No, put that down'...
|
|
|
|
|
A sheep, a drum and a snake fall off a cliff. Ba dum tss.
|
|
|
|
|
That joke hurts my insides 
|
|
|
|
|
I had the same, that's how I knew I had to share it 
|
|
|
|
|
I Kant believe it, Hulme would have thought a philosophy joke could be that good? Top Marx!
(btw, was the horse called Thomas Equinus?)
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
|
|
Sander Rossel wrote: The joke isn't funny if you have to explain it.
Ahh, now I get it
... that is: why physics is so boring.
(at least chemistry has explosions and some of biology made people cringe, so yeah, just physics.)
Message Signature
(Click to edit ->)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
