In our organization project managers are responsible for writing manual tests scripts that are to be executed later by testers. However, we found hard to find the right level of details. The right means giving valuable feedback about product.
We tried the following approaches:
Option 1: Project manager writes tests with high-level perspective, e.g. "Create a user and verify it in DB", instead of "Go to view A, click B and enter C. Expect, the user has been added to the table D". The result of those tests was somehow frustrating to both project managers and testers. As test scripts were ambigous to testers who did not know the specification of product well, so was the feedback given to project managers. Additionally, in some cases, this has shown that project manager did not attempt to write details of expected output, because he did not know the application to build well.
Option 2: Project manager writes detailed tests for the testers. This has the advantage the project manager must understand the application under controls well. He uses all his creativity to invent scenarios that have certain coverage over application functionality and risk. On other hand, there remains little room for creativity of testers. In fact, we got feedback from testers they were frustrated of doing "monkey work". So, why bother testers, if project manager wrote the tests?
Option 3: A Compromise of above. Project manager writes a subset of tests. He sits with a tester for an hour or two to introduce the application and assist during performing initial tests. They share some common sense about the application expected behaviour in general. There still remains some space for tester creativity (exploration, variations of test scenarios given), but testers stop asking questions like "Is it correct to work like this?". The meeting (one or more, if necessary) gives immediate feedback to the project manager, if the tests are little detailed or expected output for some actions has not been defined. The added value is that the tester receives training about the application. This will be useful, when he will serve as application support for customers later (yes, we use testers for both in our organization). The disadvantage is that those meetings cost the time of both persons.
There is one more approach, I would be delighted to try, if our testers had more time dedicated for our project.
Option 4: Autonomous tester team. Testers are handed specification and write tests themselves based on the specs. This is ideal situation, because they have time to understand the application domain, while still use their experience to create useful tests.
How do you write tests for testers if you do not have budget for Option 4 and still want to do better than Options 1, 2 and 3?