In very short
Yes, the synergy with a light user documentation can be a good solution for your problem.
All the details
The ideal approach, from a quality assurance point of view, would of course to have fully automated test that you can run systematically after each change, to check the regression. If you can go into that direction, go for it.
Real life constraints
Nevertheless, it's not always possible. If you are for example writing an enterprise software (e.g. an ERP or a CRM system), you'll discover a lot of requirements on the fly and have to adapt your product accordingly. Automated end-to-end tests are difficult to maintain at this stage in view of the frequent evolutions, and sometimes radical changes.
If you're developing a complex software in a smaller organisation, it's even worse, because even if the automated approach would be feasible, you'll not have the resources to go for it. So creativity is required.
The same issue applies to manual test cases. Those describe step by step each action to be performed by the tester together with the expected response/behavior/results of the sytem. Unfortunately, these detailed test specifications are time-consuming to write and almost as difficult to maintain as automated tests.
User documentation and synergies
On the other side, you'll often need to produce some kind of documentation for the end-users. A possible synergy would then to use this end-user documentation for the new developpers (or even the older ones, since the system grows significantly) to guide them step by step in the tests.
Not all the user documentations are equal. The big, comprehensive user manual of 50-200 pages will be of new use here: testing would require to put together pieces of explanations spread over multiple chapters. Moreover testers (especially if integrated in the development team) do not have the time or patience to read it all. Interestingly, users are also often lost in thos manuals.
Business process-oriented manuals produced iteratively
- A first document describes briefly the big picture: the end-to end business process flow, the list of the steps, and how they relate to each other.
- For every process step: the scenario for the user, step by step
- Then you would complete by adding some addition documents for the variants (a scenario for a special case or an error situation).
This kind of documentation can be produced incrementally with the software itself:
- During the early development phase, this documentation would be maintained in a draft form (no fancy graphics or screenshots).
- The process-step docs would evolve as you add new features. Every process sheet would present the sequence of actions from the user perspective, with explanation about the fields to fill.
- Only when the user interface appears much stabler, and the first shipment approaches, should an end-product quality level be considered, with graphical design and screenshots insertion, as well as fine-tuning of the wording.
Using these kind of documents for test is a totally winning approach:
- new developper can easily learn what he/she has to test and the expected result
- if the documentation is ambiguous, the developper can report/correct the issues, improving the documentation in each iteration exactly as the software would be improved.
- The tester would then execute the scenario with some hypothetical data
- At the end, you have a fine-tuned documentation that is really helpful to end-users.
Use cases or user-stories ?
"Business process oriented" means that we provide the big picture, regardless of how requirements are provided !
Some further synergies can be envisaged:
- If you use use-cases: a use case describes relevant goals and scenarios that matter for the users. Typically, you'll find an easy mapping between a a use case or a use-case step and a business process step.
- If you use user stories, it depends at which level the story is. But if you'd use user story mapping, then the big picture emerges and you'll find the relevant mapping with the documentation.
I could experience on several larger projects very good results using this approach of combining acceptance testing and user documentation:
- One big advantage is that many people without prior knowledge could make tests with this approach. In addition, newcomers in the team can faster grasp how the pieces of the system fit together.
- The other benefit is that this approach consumes less resources than keeping test scripts and used documentation completely separate.