In my roles, wherever I’ve worked, I’ve often been asked to test a new piece of functionality that had only vague requirements and came with little in the way of instruction. In addition to testing it, I also had to work out what the process was either by asking people, or by good old fashioned trial and error.
I’d usually then document that process for myself, either for test scripts, or as a cheat sheet to remind myself what was the next step, after I come back from documenting a defect.
For quite a few of these, I would then find myself co-ordinating UAT; sitting with the user and walking them through the process to determine if what they’ve got at the endpoint matches up with what they wanted in the first place.
This user isn’t usually the only person to be using the new functionality, and they’ll end up going back and going through it all with their team.
What struck me after going through this a couple of times was that I’ve got the process there, documented – and this would be of real benefit as a training aid. It’s not usually especially user-friendly in the form of a test script or cheat sheet, but spending just an extra 20 minutes tidying up the formatting and adding a few screenshots, and you’ve suddenly got an attractive one or two sheet training document that can be handed to the user along with the new code.
Most of the work was being done anyway, so you’re not doing much extra, and I’ve found that the users really appreciate it. I’ve mentioned before about adding value and contributing to the overall solution – this is just another example of how a tester can bring more to the table than might be immediately apparent.