Collect Requirements is the process of determining, documenting, and managing stakeholder needs and requirements. The project itself will already have requirements for Build, so what are the requirements for test management? What can we use as the inputs and tools/techniques to determine our test project requirements?
As a test manager the first requirement you will gather from one of your stakeholders is from the charter – what test phase(s) are you responsible for, and what other tasks for other phases are you responsible for? For example, you may be responsible for delivering the full end to end test scope including unit/assembly testing, system/integration testing, user acceptance testing, and non-functional testing, including all test cases/scenarios and planning for all testers. Or your system integrator may cover the unit and integration and you’re responsible for user acceptance. Or your system integrator covers unit and integration but you’re still responsible for integration scenarios being run by them on your behalf, and a separate internal technical team looks after performance testing. Your test scope will be individual to your project and as you can see, due to the potential overlap of responsibilities between yourself and other teams, needs to be carefully detailed so that you don’t have multiple teams doing the same thing or (worse) nobody doing it.
Other stakeholders will have different test requirements; for example:
- Testers will require timelines, test cases, test scenarios, a test plan, a test location with required hardware/software, etc.
- Business managers will need to know your timelines and test plan and estimated hit on their people so they can release testers to the project without significant impact on their day-to-day business.
- Project management and the communications team will require accurate reporting and metrics.
- Business and project team members will need to know any entry and exit criteria, how these are managed, and the transition between states from build to test to the future “to-be” test processes.
- Security and audit teams will have specific requirements around testing with roles and authorisations, segregation of duties, approval workflows, and controls.
In order to determine and document many of these requirements you may need to use many of the tools and techniques in the infographic above. Techniques used successfully in collecting test requirements include:
- Document analysis of project arrangements. This may include analysis of contracts, blueprint and project kickoff documents, and any RASCI matrices.
- Interviews with stakeholders. For example, informally meeting with project management and communication teams will determine their requirements for reporting and for issuing status updates.
- Focus groups with each stream can determine their perception of risk in each module and the areas that require more attention in testing. The groups can also be used to clarify the extent of testing, for example in interfaces to third parties or in the inclusion or otherwise of 3PLs and other associated entities such as regional sales offices.
- Facilitated workshops between the test team, project workstreams, and business experts can drive out test scenarios. Workshops can also lay out the strategy for who will be writing and approving the scenarios and the timeline for essential activities.
- Mind mapping and brainstorming sessions on a whiteboard can be used to work through complex issues such as test prioritisation or test client / test data timeframes.
- Surveys can be used, for example, to determine tester training needs on test tools.
- Prototypes of test structure in the test management tool can be used to walk through design of test case management.
From collecting requirements you can then create your test plan (8.1 Plan Quality Management), plan to procure any necessary hardware and supplies (12.1 Plan Procurement Management), and manage your test scope (5.3 Define Scope, 5.4 Create WBS, 5.5 Validate Scope, and 5.6 Control Scope). SAP projects frequently use a Requirements Traceability Matrix for build deliverables, and your test requirements should at a minimum be able to cover the requirements in the RTM.
|Previous Page - 6.5 Estimate Activity Durations||Next Page - 11.1 Plan Risk Management|