|
How much authority can a tester have?
I'm a little confused on the scene I'm watching.
I see emails flying across from a tester almost with a CEO level authority, like:
"These are critical bugs fix it ASAP!".
Btw, it;s are not as critical as it's claimed to be. And the developer assigned to this is more experienced than the tester issuing these instructions.
I always believed testers role is to test, find the results and log them in Bug tracking tool.
Should they be allowed to send these "Directional" commands?
I see it very commanding. Sometimes it's very ironic to see, the hard-working developer race is often mistreated. Right from the dumb product manager to a tester anybody is able to command and react on a mistake done by the developer.
Should I stop the tester from sending direct instructions to the developer?
|
|
|
|
|
Nand32 wrote: I see emails flying across from a tester almost with a CEO level authority, like:
"These are critical bugs fix it ASAP!".
So fix it, and reply: It's fixed: Test it AND SUBMIT sign-off ASAP.
Edit:
also:
until the tester has completed all of the testing you can also reply:
-> please complete ALL testing ASAP so we can schedule all required tasks ACCORDING TO THEIR PRIORITY!
(in that you've taken away all their determination and authority of what's important or not.)
Message Signature
(Click to edit ->)
modified 19-Sep-19 7:17am.
|
|
|
|
|
Quote: -> please complete ALL testing ASAP so we can schedule all required tasks ACCORDING TO THEIR PRIORITY!
(in that you've taken away all their determination and authority of what's important or not.)
You're smart 
When I was a developer, I did all these things to let the testers know where they stand & how they can behave.
|
|
|
|
|
Just because someone says this is high priority developer does not start writing code. It is job of the lead/manager/whatever you call them to look at bigger picture and understand why person A thinks it is high priority and person B says low.
So, the question should be that why does the tester think this is high priority? To get things off his queue? It is stopping from testing other cases which are somehow dependent on this? Something else.
In any case, I would not let tester dictate the plan ahead. This beats the need of having a manager (huh, that does not sound too bad!).
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
There's has been several times I've picked him and told him these are not critical bugs.
& had asked him to lower the flags. He goes back and updates the ticket.
And there was an instance where he had an argument with the developer(which I wasnt aware). then he was at my desk trying to justify a tiny-toony bug as an important one.
I had to shut him off asking not to waste time on these trivial things.
He's a bit attention-seeking.
|
|
|
|
|
Nand32 wrote: ...had asked him to lower the flags. He goes back and updates the ticket.
Adjust the bug tracking software to only allow him to report findings, not assign them a priority.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
I think he needs to understand his job role and responsibility then.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
Hmmm,
I am a Poacher turned Game Keeper in my current role (I got a Job as a Tester as I got fed up with Daytime television). In my experience, if I don't know the dev. well I tend to wander over to his desk and say 'I am doing something stupid but...' it tends go over better than 'You don't know what you are doing butt head', then I log it in the bug tracking tool as you don't want a project with a huge back log hovering. If it's a quick fix (like spelling a word wrong on the interface, happened this am!) tell them, don't raise it as a fault, raise it as an observation.
|
|
|
|
|
 You can make a great test lead. 
|
|
|
|
|
Not sure if I want the stress... 
|
|
|
|
|
That is why you need to have a good work process and compartmentalize roles.
In your situation, I would get the tester and go to your product manager and discuss the issue.
We do that often when we're not certain of a bug importance or priority.
I'd rather be phishing!
|
|
|
|
|
I'm the conflict resolution point. Both report to me. The tester is bit of an attention seeker.
|
|
|
|
|
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 one nonsensical character can trigger a whole lot of chain reactions. At times exposing all the other nonsensicals in the circle. 
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
