I have wrestled with this problem a number of times.
For instance, I have had a number of occasions where I needed to hand each member of a group of testers a stack of paper to describe the steps they had to take.
- The first time a tester needs a detailed procedure it has to be there for them to read immediately. Similarly, when the procedures are very similar but differ in important details, the procedure needs to be right there.
- Subsequent times, I don't fold the procedures into the test script, but simply refer to it by a distinguished name.
I have written a number of different tools to handle this problem, each with its own set of quirks and annoyances, for me and the people doing the testing.
My current vision of a test documentation package involves generating fairly sophisticated HTML. For instance, it might use disclosure triangles or pop-ups or pop-overs to allow the tester to view the details as often as they need in order to become familiar. The basic test documentation looks short and straightforward, with most of the detail hidden until needed.
In a similar vein, the web page with the test procedure in it would be an active form where items could be checked off as they are completed, and details written down when needed, and anomalies or bugs recorded at the exact point where they were noticed in the script. This requires some non-trivial back end software. I have looked into using a survey generator/capture tool for this kind of support of manual testing.