"'Suppose that...' -- we don't want to say that software development is like something else; (...) "Suppose it was just itself, and you didn't do any analogies for a moment, what would you see?"
"And so, what I came up with, (...) is that there are people who are inventing and communicating in the face of a problem that keeps changing, a solution that keeps changing, technology that keeps changing, out from under them all the time. They've got some end goal, they have to deliver this piece of software, they have to set up for the follow-on project, while all that there is as actions are invention and communication. And so I found it useful to talk about it in a vocabulary of a cooperative game."
New Context for Software Testing
I picked the above quotes from the IT Conversations Interview with Alistair Cockburn (Transcript) as a way to engage you into looking at a role a Software Tester could play in a context of cooperative games programmers play. It all started in 2002 when I stumbled upon an article in SD Magazine by the very same Alistair Cockburn entitled "Games Programmers Play" and I started reasoning about my role as a Software Tester on a Development Team. Could I join those games too?
In this context of Inventing and Communicating what could we say is the role of a Software Tester? What could I provide, contribute to make the game work for all? If in this game the moves I make consist entirely of inventing and communicating then how do those moves look like?
In my daily activity there is a lot more than writing and executing tests. I spend a lot of my time communicating with various people on the team. With each person I use a different language, different vocabulary. With managers I talk about time, delivery, percentages, results. With DBAs I talk SQL statements, data models. With Java developers I talk methods, exceptions, states. With customers I talk Use Cases, scenarios, happy-paths.
At some point I asked myself "What is the context for my activity as a Software Tester?" If I was just a Tester in a classical waterfall approach I would receive a Functional Specifications document and I would start designing Test Cases that would attempt to validate functional features but instead I find myself spending time sitting with developers in their cubicles and reasoning with them how a functional design should be and how to implement business requirment into functional requirement. I find myself working with developers looking at the code, having in mind future integration and system testing, taking the big picture into account while looking at classes and SQL calls. I also find myself discussing requirements with Business Analysts, drawing diagrams on a whiteboard and talking on the phone with Customers about new features and helping them articulate their requirements for improving their software. - Are these activities the software tester should be doing? Perhaps. I find myself communicating, distinguishing, synthesizing, abstracting, analogizing. Am I doing Inventing? Not sure - but I'm definitely connecting people and clarifying their ambiguities. My moves are all about communicating, perhaps to make sure that there is communication on the team. So In this context I started looking that perhaps my job as a Tester is to Support the Game. If Software Development could be cast in the context of "A Cooperative Game of Invention and Communication" then how can Software Testers support programmers in playing those games? How can Testers support this process of Invention and Communicationthat makes the game work and worth playing?