My immediate thought was 'WTF? Why would I need excuses?'.
Reasons, yes, explanations, yes, but excuses? Hell no.
Am I wrong? Do I need excuses?
Or am I getting reasons and excuses mixed up? Are some people taking them to mean the same thing?
At the end of "Excuses for testers when bugs are caught in later testing cycles/UAT/Production". There is this sentence 'Well these are not actually excuses. These can be the actual reasons why an application is shipped to client with major bugs.'
The way I understand the two in this context are:
Reasons
1.a basis or cause, as for some belief, action, fact, event, etc.: the reason for declaring war.
2.a statement presented in justification or explanation of a belief or action.
Excuses
1.to regard or judge with forgiveness or indulgence; pardon or forgive; overlook (a fault, error, etc.): Excuse his bad manners.
2.to offer an apology for; seek to remove the blame of: He excused his absence by saying that he was ill.
3.to serve as an apology or justification for; justify: Ignorance of the law excuses no one.
I am not a gate keeper, I am an information provider, I have limited time to provide what information I can.
I will do my best, the people around me will do their best and sometimes we will not be able to investigate everything.
I'm happy to explain things but make up excuses? I think that will do more harm than good.
There are plenty of reasons why issues end up in production, learn from them, explain, improve how you test and what you test.
Don't make excuses.
28/01/13 Update.
Forgot to add, what and how you are testing and what you are not testing should be communicated and continuously communicated as you delve deeper into the software.
Good post, Tony. I especially like "I am not a gate keeper, I am an information provider.." I think more people need to recognise this!
ReplyDeleteI agree, people need to recognise this. The only way that's going to happen, though, is for us to tell them!
DeleteI gave two talks at my place of work: "Introduction to software testing" and "Introduction to exploratory testing", mainly to show my manager, fellow testers and developers what my job actually is. To show them that I am an explorer, and I serve in support of development not against them.
I think excuses in terms of justification are only valid when backed up by evidence and valid explanation. I think reasons in terms of causes of this problem are only valid under similar circumstances.
ReplyDeleteSo if it does occur I use a mix. I state what the problems were, "excuses" as to why this may have happened, reasons why it might be more likely that it happened, and what we can do differently so that it happens less frequently (pointing out, of course, that it always still can). It's also a good opportunity to voice testability concerns.
Also I think if people are having to look up excuses (with all the guilt that word evokes) for their testing then there's a problem with either a blame culture in their company and/or how they are communicating their testing in the first place.
Are there really usually _reasons_ for a bug in production? "out of the many things we tested in an infinite test space that specific scenario wasn't one of them"... or perhaps it's a good opportunity to requisition resource, expand quality criteria, rethink risk priorities and so on. If you understand what you're testing, and what you're not testing, then you know what you need to add to cover the kind of thing that was found in production (and if it's cost-effective to do so!).
I think it depends on the context that you have to supply the reason, as to whether an excuse is supplied...
ReplyDeleteExcuses will be common where there's a blame culture in the organisation, where people quickly want to make excuses to pass the buck away from themselves as to not receive any punishment: "But I couldnt test this because it was the developer's fault for supplying it so late!!"...
I also think that over time in this situation, the meaning of both (excuses and reasons) have basically become a blur with some people.
It's important to differentiate between them both.
Great post Tony!!
Thanks Tony,
ReplyDeleteIf we found the bug in the production environment during the release testing.
And the scenario,which is not developed/missed by developers also.
Is that fault goes to Testers as punishment?
Testers have to excuse for this..for not seeing before release?
Hi Srinivas,
ReplyDeleteThanks for commenting.
The 'fault' goes to the whole team.
We are all working on this system.
Testers (and anybody else) cannot possibly see everything so we need to prioritise and focus and communicate to everybody what we are prioritising and focusing on.
If there are any concerns from anybody they can be raised and dealt with.
Hi Tony,
ReplyDeleteIn my experience, whether *you* think you're offering excuses or reasons is often immaterial. The person you're talking to will make their own interpretation based on their own expectations, experience, context etc.
My conclusion would be the same as yours, though I think: try to state clearly, concisely, consistently and as completely as required what you did/didn't do and what you found, with analysis if appropriate and without prejudice if possible :)
Coincidentally I wrote about responses to finding bugs in production this week too, although from a different starting point: http://qahiccupps.blogspot.co.uk/2013/01/context-driven-answering.html
Exceptional project management and regular communication, the team expertly handled position turnover and ensured that all deadlines were met.
ReplyDeleteTheir team is incredibly prompt and responsive, quickly responding HDMI to VGA Connectors to all or any queries in the least hours of the day.
ReplyDelete