So how do we solve the scripting problem?

Again, in the unlikely event that you read my blog before you read James‘ blog.

One of James’ correspondents, who sometimes goes by the name “Ben Simo”, is a very sharp fellow, as evinced by some of his posts on the software-testing mailing list. In response to our conversation about scripted test procedures, Ben asked a question that I think is important.

How do we teach script writers to lock down those things that need to be locked down? When I ask questions to try to nail down some of the ambiguity, I get the impression that the script writers think I’m trying to make simple things difficult.

Here’s how I think we could go about it. I’ve ranked these–the most urgent first and the most important last.

The first step is to acknowledge, from the beginning and repeatedly after that, that you’re trying to help–and that you’re not trying to be pedantic or a pain; you want to avoid the risk of misinterpreting an idea that might be important.

The second is to remind them that, as a tester, it’s your job to consider questions and possibilities that other people don’t consider. You might like to, on occasion, recognize with the other person that it’s is a peculiar and potentially funny occupational hazard. For one thing, I’d suggest joking about it every now and then.

The third is to try to solve the problem by ways other than locking people down. (Hands up, everyone who likes to be locked down.) Consider things like culture, common language, shared idioms, mentoring, training, observation, participation, collaboration,… These might suggest alternative ways of understanding one another.

Fourth, and most importantly: when you write a test script, either for automation or (ugh!) for human testers, it’s to further some purpose, to answer some question about the product. Maybe if you understand the question that’s being asked, to whom it matters, and why it matters, clarity of each and every little individual step doesn’t matter. What matters is the fundamental question of testing–”is there a problem here?”–closely followed by, “if I’m automating a test, what problem am I hoping to identify? How will this script help me to identify that problem? What steps would the script need to perform to get to that identification? What problems might I miss?” At that point, you-the-toolsmith can write the script without painful interrogation of some poor soul who might not know how to break the task down in a way that’s entirely helpful to you. Making that translation from risk and test ideas to scripts expertly, without the need for hand-holding, is the real centre of skilled toolsmithing to me.