Practitioner, manager, and consultant Stephen Vance explains why we still need testers. Instead of just using the testing process at the end of a development cycle, Vance argues for integrated testing that solves issues throughout the process.
Josiah: I’m joined by Stephen Vance, who’s a practitioner, manager, and consultant. Stephen, thank you very much for joining us today.
Stephen: Thank you, Josiah.
Josiah: First, could you tell us just a bit about your experience in the industry?
Stephen: I’ve come up through the ranks as primarily a developer. I’ve been programming since I was twelve, but didn’t think of it as a career option until after college. That’s been a little bit further away than I’d like to admit, but I’ve been at it for a couple of decades now.
I’ve pretty much worn just about any hat in the industry. I’ve been a manager of developers, of QE, served in a lot of the front-line roles… still keep a fairly deep hand in a lot of the technical implementation then also serving as an agile coach. Self-employed, large corporations, startups, you name it.
Josiah: Why do you think it’s so difficult for people to include and also engage testers during scrum meetings?
Stephen: I think probably the biggest thing, there is a shortage of understanding and of what the tester’s essential skills are and how they can be integrated were effectively. I think a lot of people in the industry, and probably in the world at large, think of themselves very much… They place their value in the output of their work product, rather than the actual skill they bring to the table.
Speaking specifically to testers, I think a lot of the time they put their value in the bugs they write or the test cases they write or the execution of the test case rather than the essential skill that they actually bring to the table. In the same way, I think a lot of developers put way too much value in the code they write rather than the problems they solve.
Josiah: In your own words, could you just describe a bit about what you consider the testers mindset?
Stephen: Yeah, that’s really about these essential skills there. Testers bring a different way of looking at things. It’s an inquisitiveness, an exploratory nature, an investigative nature, tying a bit into what I’ll talk about in the talk in the fall, a sort of hypothesis-driven nature. In a lot of ways, it’s divergent thinking and I mean that as opposed to convergent thinking not more deviant part of the movie of recent.
Josiah: I’ve been talking to a lot of different people who are going to be talking at STARWEST and I’ve heard some people saying testers are necessary. Then, other people talk about automated testing is taking over. I know Facebook does, in a lot of ways they don’t even really test. They’re just like go, go, go, and they update it as they go. Why do you think the tester’s mindset is still so important? Even with the automated testing continuing to expand its presence in the industry?
Stephen: Really two things I think are very important. The first is that automated testing really captures human reasoning about behavior. In that sense, you still need a human to reason in order to know what to automate. The tester’s mindset’s absolutely essential there.
If you just test for the straightforward paths and don’t worry about the variance you’re really not going to have a complete product. You can wait until your customers find it and for certain audiences that’s fine, but for most companies they don’t want to have that image. A lot of the time they don’t have good enough engineering practices to be willing to take that chance, so really having the tester’s mindset’s fueling that automation is absolutely essential.
The other thing is that at least for the foreseeable future, there will always be things that either can’t be automated, or are worth automating. A lot of these things involve complex interactions and honestly writing automated test for really complex interactions, especially intricate, distributed systems, is a really complex, nontrivial, and sometimes almost impossible task. There’s plenty of room for people and their creativity to explore that and interact with systems.
The other is that there are a lot of human usability and anesthetic judgments that you’re just not going to program a computer to make. You get companies like Google who have, yes, they’ve automated the comparison of for example, the image of a web paging consecutive versions of the application to highlight where the differences are. That’s not a substitute for knowing whether it’s aesthetically pleasing; whether it’s easy to use; whether you know the intuitive gotchas.
We really need exploratory testing for these things. We need human judgment and really what I see the role of automation doing is freeing up the tester from the things that would basically keep them tied to the assembly line. We don’t need testers to press buttons. We don’t need testers to execute the same recipe over and over. We want humans who actually can think and design and explore.
Josiah: Would you argue that projects tend to reach a higher quality bar when testers and testing is involved early in the development process and if so, why?
Stephen: Absolutely and this is really the essence of my talk in that I think that there’s something that the testers bring to the table. If you can take that exploratory nature and, what I referred earlier to hypothesis driven, I mean really, what a testers doing is they’re not just saying let’s wildly flailing at this application and see what breaks. There’s a value in that, but there’s also a reason that’s called monkey testing sometimes.
What they’re really doing is they’re saying I have a hypothesis about the way this application works or the way it was implemented for the way it’s supposed to work. I’m going to execute some recipes to put some variants around that and to really explore the boundaries of that and the purpose of that, so you’re forming a hypothesis about what might break or forming a hypothesis about what should work and then executing against that hypothesis.
Bringing the tester’s inquisitiveness into the formation of that hypothesis can immensely increase the quality of the resulting code. This comes to one of the things that I think is one of the most frequent breakdowns in especially traditional development processes, is that the idea that testers will go off and write a test plan in parallel to the development essentially means that they’re creating a set of shadow-acceptance criteria.
They’re creating a target for the application development that’s different from what the developers think they’re writing to. The result is that you get a complex of expectations. I think it’s really one of the major sources of a lot of the tensions between traditionally developers and testers in that the testers are holding the code to a standard that the developers didn’t know about.
Josiah: You mentioned the tension between developers and testers, like I had said earlier, I’ve talked to a lot of people where it seems like there’s just these varying values of what testers do. Are they still important? Should things be automated?
What can we do to put a greater spotlight on testers because I would argue that you’re saying testers are still very important especially from the beginning of the process, we need testers. What can we do to maybe help show people that they're needed and that the work that they do is very important?
Stephen: I would say that the real key to that is emphasize their skill contribution and bring it in early rather than put the emphasis on the artifacts that they produce. If you can get them talking with the developers and interacting and even pairing with the developers whether they have the same level of coding or not, it helps if they do, but if they don’t.
I’ve gotten teams to work together effectively where the tester still has be able to speak the language and essentially the developer access the translator in code. You can do that in a way that’s highly collaborative and interactive and produces a much higher quality result right out of the gate. I think that really puts the spotlight there. I once said to a QE manager “I’ll know that we’ve succeeded in getting this collaboration thing when the testers ask why there on a different pay scale.”
Josiah: (Laughs). All right, fantastic. I really appreciate your time, Stephen. I’m looking forward to your talk in just a couple of months. Yeah, I’m really excited to hear more what you have to say about testing and the importance of testers in software.
Stephen: Glad to, thank you very much. I’m looking forward to it as well.
Josiah: All right, thanks.
Stephen: All right, see you there.
Stephen Vance (@StephenRVance, www.vance.com) has served in most roles in the software product development process across a wide range of industries and technologies from startups to Fortune 100. As a practitioner, manager, and consultant for the past several years, Stephen has focused on coaching teams in lean and agile approaches to development and testing. Currently an independent lean/agile coach, he is the author of Quality Code: Software Testing Principles, Practices, and Patterns.
