In this video, Dawn Haynes explains why it is so important for testers to focus on understanding the context of a project and providing useful information to stakeholders rather than spending countless hours attempting to track down every single bug they possibly can.
So, I think, a lot of testers overtime get kind of downtrodden. I find new testers kind of spunky. Right? They're all excited and they find all kind of problems and they're really happy. And then, as they figure something out, that not all their bugs are going to get fixed... And I learned that on my first project.
In my first project I had the title of QA Engineer - quality assurance. Reflecting back on it, I didn't assure anything. I wish someone would have told me that then. It would have been different. How I interacted with team members would have been different. But instead, "quality assurance." I thought that meant that I decide what the quality bar is, and I dictate to other people what will be fixed and what won't be. So, I walked around the building with my giant quality bat and I just beat people with it. And that was not a joyous occasion, because people started to dislike interacting with me -- just imagine that -- because I'm a bit of a pit bull when I believe something truly. When it means something to me.
And I believe a lot of testers are connected to that - connected to the notion of quality. The notion of, you know, I'll call it pride in our work, is tied to the information we share being valued. And a lot of time on projects, people/stakeholders/developers prove to us with their actions and their words that what we do is not valued. So I think we seek validation. And if you think about it, how do you know you're a good tester?
Well, for me on my first project, it's how many bugs I write. I don't get paid by the bug, but I'll tell you something about my mindset: If the end of the day came, the end of the work day, and I had not found a bug yet, "Oh it's on like Donkey Kong!" I am going to sit there, and I am going to be there all night until I find something to file.That's ridiculous. I can't believe I did that. I can't believe it mattered that much to me - that I find bugs. Because I correlated that to my success in my job.
Now I'm more a seeker of information. And I've had a great number of mentors, colleagues and friends in the testing industry that have guided my thinking: James Bach, Elisabeth Hendrickson, Scott Barber, Rob Sab. So many of these people -- Mike Kelley, excellent -- really changed my way of thinking and my approach in testing. And what I wouldn't give in retrospect to have had any of that on my first project. And the one piece of information that is shinier than all the rest is something that Elizabeth Hendrickson shared with me. And I'm pretty sure she got it from a lot of other people, so I'm not sure where it came from originally, but she said, "testing is an information service."
Service. *Ding ding ding ding*
I came from tech support and customer service. I walked across the hall to go do a QA job. I didn't have any training. I didn't have any books to read. I was abandoned. I was left alone, the sole tester on a project with 10 UNIX boxes as my friends. How did I know I was doing a good job? I had no idea.
And the first time a product manager came in -- product/project manager, he was kind of both -- and he said, "So, how's it going? When do you think you're going to be done?"
And I was like, "Done? There's no 'done' here. I will never be 'done.' I will test from now until the sun explodes, or you pry this out of my cold, dead hands."
I could not envision a place where I would be "done" with the actual testing that I had in front of me. I had 144,000 configurations to test. No "done" here. I was getting a build a day. It was awesome.
So, I could not help this person. "When are we going to be done? How's it looking?" I was like, "No, never." So, that was our conversation on the first day. The second day he came back and asked the same question again and I went, "Same answer dude. Did you forget? It was just yesterday." The third day he came back and before he said anything I went, "Stop! Do not ask that question again, because the answer is always going to be the same. Forever. So as far as I'm concerned, ship it whenever you want. I have no information that can help you."
And I didn't. I didn't have any information that could help him, because I didn't understand what information would be useful. Now, if anyone (anyone) had said, "testing is any information service," I would have said, "Oh, oh! Alright! What information do you need?" Right?
It's not just about the testing. It's about, kind of, the results and summing it up. So it's not metrics and measures and quantitative analysis. It's "What do you need to know? What decision are you making? What judgments are you weighing? What does a good product look like to you?"