- Prepare (preferably thousands of) detailed test scripts based on functional designs
- Deliver a detailed (re)planning of all test activities over different phases and environments
There are however, other useful things you can do while waiting for a product to be released.
Those might not be directly required by your PM, but you'll benefit from them later on the critical path.
This list is not exhaustive as exhaustive lists would be exhausting.
- Talk to business users and analysts. Ask them about what they think is important, ask them how business works. Create your high level business End to End test scenario's in a workshop. Compare those End to End scenario's with functional designs and requirements and deliver your first gap analysis results. Explain your test approach to business users and analysts. The end to end flows can give you a nice way later on to report back to business on your test progress in a way they will all understand. I'll come back to this later on in a specific blogpost.
- Talk to developers. Ask them about the programming issues and re-used components. This can save you some time later on. There is a reason why development will deliver late... Agree with them about the defect template and the procedure... that you want to keep as pragmatic as possible.
- Read trough the analysis documents and identify high level test cases. Make note of inconsistencies and communicate about them on a regular base. These are very likely places where bugs can be found if not taken into account. It's perfectly sane behavior for a tester to make some commotion if you're not listened to during this moment in time.
- Challenge the Architectural picture with what you learned from the business users and developers and read in the documentation. Make again note of inconsistencies and communicate them.
- Create a high level overview of all test activities that need to take place. Agree with all parties that will take part in testing and find inter-dependencies over the available test environments. Find out which test activities can be run in parallel. Find out when, most likely, data resets will be required. Verify when other test activities in the environments are planned. Get to know your testing neighbors.
- Define your reporting structure and agree with your PM and business. Use some visible examples. Make sure everyone understands that metrics are not the only thing they want to receive. Try to be creative and present visual, simple reports and arrange the possibility to have meeting to explain your status.
- Train your BA's and other non-testers who will be joining in testing at some moment in time. Your mission is to make them become better testers. Tell them why writing all possible variations for a field validation test is an endless activity. A tester will have endless amounts of test cases to test one field but might only execute some for which the product will likely manifest bugs. You could tell them something about Boundary value analysis, data combination, paths, about focussing and defocussing, the tea-test and the shoe-test.
- Make sure you obtain access to the test environment(s) with the correct user roles and assess if all infrastructural components, required to start testing, are in place.
- Test the test data backup and restore process. If you have the possibility, make a proof of concept.
- Prepare your assessment on entry criteria if required and give your development team a heads up on where they are in function of your entry criteria. In this way they won't be surprised when you need to give them a no-go to deploy in the test environment.
- Test the deployment and release procedures.
- Implement required test tools.
- Reassure the PM, they are nervous and need some support.