Mistakes
"The great question is not whether you have failed, but whether you are content with failure."
— William Shakespeare
That is a great quote to bring to a contested bug deferral.
I got into a conversation about testing mistakes with someone. I don't know any practicing testers in the industry who do not have at least one bug they have shipped with which they really regret and feel ashamed of.
When I was a brand new tester, working on contract at a big company, I was assigned an area of the product which had been tested. It was legacy code and I was handed an existing spreadsheet of well defined test cases along with a spec and test plan. I went about running all of the test cases and even went off of the script from time to time. When we shipped, I certified the milestone and felt great about how well tested my area was.
Then a bug came back that if you were to drag anything over one disabled icon in a peice of UI that was MY responsibility, the application would crash! This blew my mind. I had already checked that it was disabled in the script. How could it not be disabled? It was greyed out, not disabled.
With such an obvious miss, why am I still testing? Should I have been fired? Why did they let me continue my contract? I am still testing because I learned something very useful from that missed bug. I am more curious, skeptical, and I do not follow scripted test cases a majority of the time. Missing a bug is not a good reason to fire testers. In my opinion, dishonesty, being burned out, not testing, not learning, not working with other people, not communicating, doing the minimum required, needing constant hand holding, having no passion, being brain disengaged, and refusing to seek your own answers should be career limiting offenses. Those are good reasons that you shouldn't be testing. Making a mistake is not. Being human is not. Doing the best you can with an unreasonable schedule should not, so long as you communicate the risk.
I feel that if you aren't making any mistakes, you should be increasing the level of risk that you take.
— William Shakespeare
That is a great quote to bring to a contested bug deferral.
I got into a conversation about testing mistakes with someone. I don't know any practicing testers in the industry who do not have at least one bug they have shipped with which they really regret and feel ashamed of.
When I was a brand new tester, working on contract at a big company, I was assigned an area of the product which had been tested. It was legacy code and I was handed an existing spreadsheet of well defined test cases along with a spec and test plan. I went about running all of the test cases and even went off of the script from time to time. When we shipped, I certified the milestone and felt great about how well tested my area was.
Then a bug came back that if you were to drag anything over one disabled icon in a peice of UI that was MY responsibility, the application would crash! This blew my mind. I had already checked that it was disabled in the script. How could it not be disabled? It was greyed out, not disabled.
With such an obvious miss, why am I still testing? Should I have been fired? Why did they let me continue my contract? I am still testing because I learned something very useful from that missed bug. I am more curious, skeptical, and I do not follow scripted test cases a majority of the time. Missing a bug is not a good reason to fire testers. In my opinion, dishonesty, being burned out, not testing, not learning, not working with other people, not communicating, doing the minimum required, needing constant hand holding, having no passion, being brain disengaged, and refusing to seek your own answers should be career limiting offenses. Those are good reasons that you shouldn't be testing. Making a mistake is not. Being human is not. Doing the best you can with an unreasonable schedule should not, so long as you communicate the risk.
I feel that if you aren't making any mistakes, you should be increasing the level of risk that you take.
Robert Kiyosaki has a quote that I like: When you reach the limit of what you know, it's time to go make some mistakes.
Reply to this