My sister was visiting us a few weeks ago so that she might meet her new niece in person. She lives about 1500km away from us, so it’s just far enough away to make these sorts of visits infrequent.
I learned a lot.
I watched her reverse-engineer a song that I’d been singing to my son and reduced it to its essentials so that I might learn to play it on the piano. In about a minute and a half, she identified the major chord and said, “just play around with that chord with the right rhythm and you’ll get it”.
I didn’t believe it.
That is, until I started playing the song, a couple of weeks after she left. Her gift – countless hours of practice as a performer and teacher that made it possible notwithstanding – was to show me the essentials, guide me with just enough to get started, and then to let me go experiment for myself.
I didn’t get a lesson plan.
She didn’t give me a script, a transcribed version of the song into notes on the paper. She didn’t tell me the rhythm, she let me feel that out for myself. She didn’t tell me what to do when.
Turns out this is what checklists should do for testers, especially those business testers that are not necessarily software test professionals in the first place. They know their business. They know how to use a computer. They need guidance, but as I didn’t need a script to learn a song on the piano, they don’t need a script to test effectively.
In my experience, the more we tell our testers what to do, how to do it, in what order, how often, etc., the more likely it is that they will do just that. And only that. Sticking to script is rarely a good thing in testing.
Checklist items are chords, not notes. If you believe the tester is a person, a sentient being capable of putting emotional labour and thought into their work, then identifying the chords is enough. They will play the notes without you going through the effort of transcribing them.
Give them room to create their own art.
