Just got asked by an end-user whether they needed to put screenshots into their test scripts... Now test-scripts are only partially for the benefit of the developer; they also serve the end-users and maybe audit, depending on the organisation. This was a pretty simple application (no spec, just a few conversations) for an end-user with whom I've got a good relationship. I'd done a bit of to-ing and fro-ing, had a few sit-down sessions where we point at the screen and talk about adjustments and how to use the app, along with it's supporting reports etc, but not got to the stage where we'd formally tested.
As far as I'm concerned, people do test-documents with a mixture of 3 attitudes:
1 I just want it done, get it
into PRD as soon as possible
In which case, you’re shooting
for the bare minimum that the CAB board will accept to put it into PRD. You
probably don’t need screenshots, you could get away with a text description,
replacing “Screenshot of” with “We tested and saw”.
2 I want a resilient, well
tested application that suits my requirements and what I asked for.
In which case, you describe the
end-to-end process (new joiners, new users, updates to policy documents,
mailing users to prompt them for un-acknowledged policies, facility to review
who has/has not acknowledged etc) with expectations of results at each stage.
You then run through the entire process, and highlight where the program’s
behaviour differs from your expectations.
3 I want to make sure the
Customer hasn’t got anything to bash my backside with in the future.
A testing document set up by the
customer/apps consultant allows us to confirm that the application has passed
any test that was agreed upon, and that any future amendments to the
application(s) are either bugs that weren’t picked up in testing, or changes
that have subsequently arisen.
In this case, owing to the good relationship, I'm not worried about 3, and the simplicity of the app means I'm not worried about 2, so that left me with 1...
I can't force users to test stuff before pushing to Production, but if I don't, I have to be prepared for the potential of a bunch of re-work!
