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.