The key benefit of the Define Scope process is that it describes the boundaries of your responsibilities by defining which of the requirements collected in 5.2 Collect Requirements are included in your test deliverables and, to a certain extent, how they will be delivered. From a test management perspective there are four distinct areas of scope that need to be defined and agreed: Phase Scope, Architectural (Technical) Scope, Functional Scope, and Execution Scope. The defining of these areas of scope as an output will usually be included in your Test Strategy document.
SAP projects generally follow a waterfall SDLC – Blueprint (Design), Build, Test – and the testing phase invariably follows some version of the V-model of validation stages – Unit Testing, Integration Testing, User Acceptance Testing. Each of these stages can be broken down further into Planning, Preparation, and Execution. Each of these sub-stages contain multiple tasks and activities, which should be separated into deliverables and allocated to high-level teams (Solution Delivery Test, Business Test, Solution Delivery Development, Business Analysts, etc) and agreed with the leads of each of those teams. The responsibility for each of these tasks will vary from project to project and it’s entirely possible to be responsible for tasks and activities within a sub-stage but to not be responsible for the overall test stage. For example, you might be responsible (together with the development lead) for defining a framework for unit testing and determining what the test conditions/cases and test results look like, but the development lead is responsible for overall Unit Test execution. Or your Unit Test execution might be split between Technical Unit Testing (and owned by Development) and Functional Unit Testing (and owned by the configuration streams). Or you might find that you are responsible for gathering test scenarios / user stories to be used for Integration Testing but that the execution is run by the system integrator.
Project documentation and facilitated workshops with project management and team leads will assist you in identifying and clarifying each stage and sub-stage within your test phase and will enable you to build up your test strategy,
Bear in mind at all times that various parties may have contractual obligations to deliver certain stages; therefore, it is imperative that you identify clearly the test phase scope that you are responsible for.
Architectural (Technical) Scope:
Within any SAP implementation there can be multiple components and modules, plus external systems and applications, and not all of these may fall under the remit of the project SAP test manager. Further, due to constraints in time, budget, and/or people, not all requirements may be able to be delivered to the extent that they have been requested, and formally defining the technical and functional scope enables discussion on what can be tested by your team, what will be tested by other teams, and what will be omitted altogether.
Defining the initial scope boundaries can be achieved through workshops and discussion forums, to outline what components are in scope, what plants, third parties, and the edges of responsibility. Ongoing analysis of organisational assets such as risk and issue registers will also define further the technical scope of your testing, and regular co-ordination between the test manager, project manager, and development manager will refine the final scope.
The initial architectural scope can be defined early as part of the test strategy, and your starting assumption must be that everything in this scope will be delivered. The refinement of and any exclusions or additions to this scope due to the constraints mentioned above will be treated as exceptions throughout the Monitoring and Controlling process.
Functional testing of process flows through an SAP system will be the bread-and-butter of your testing. But what about all the other aspects of testing? Data testing, Internal Security (roles and authorisations), Internal Audit (Segregation of Duties and audit controls), External Security (penetration testing), Performance testing (networks and interfaces, including load, stress, and recovery testing and network scalability), Localisation (languages and legal/regulatory), Brand consistency on documentation, Disaster Recovery testing, etc
Due to the specialist nature of much of this testing it can frequently be assigned to other internal or external teams to plan and execute. Again, project documentation and facilitated workshops with project management and team leads will assist you in identifying and clarifying what testing is necessary within the context of your project and who will be responsible for managing (and if necessary procuring the expertise for) the testing.
For test execution you will have challenges such as the amount of time available to test, the number and coverage of scenarios, and the number of testers available and their experience on SAP, that will limit the amount of testing you can perform. Risk-based assessments of the Fit-Gap and/or the Requirements Traceability Matrix can lead you to assess each requirement for it’s criticality (high-medium-low, or red-amber-green, or a similar assessment) against which you can allocate test scenarios, testers, and time. Alternatively you could start with the test scenarios and assess business risk and impact of failure of each scenario and work backwards to ensure your selected scenarios cover the RTM, with a greater emphasis on scenarios that have a higher risk and impact of failure. An analysis of estimated time to execute a scenario vs available capacity of your test team will provide a guide as to whether your test coverage can be achieved in the time available.
Expert judgement is often used by the test manager to then develop the approach to refining the final scope, and risk analysis and assessments are frequently the tool used. Where you have a capable and experienced team you may also want to explore the different experiences of the team members to generate alternative options and approaches to execute the testing without unduly compromising the integrity of the quality and minimising risk to the business.
You may also have challenges such as budget constraints for a test lab that reduce the availability of test machines, or a limited amount of hardware such as scanners or printers that would slow down your testing. These are still requirements where the scope needs to be defined and the impact on overall testing assessed to ensure you are not over-promising what you can deliver.
The test scope statement documents the scope. This may be one or more documents including the Test Strategy to define the test phases you are responsible for, the technical scope of testing, the split between functional and non-functional, the test approach for dealing with all of these, and assumptions and exclusions in your scope; the RASCI matrix to detail ownership of test stages; the project WRICEF register detailing some of the the technical scope; Fit-Gap and RTM to identify the technical scope and requirements; and the Risks and Issues register to detail any constraints.
|Previous Page - 5.1 Plan Scope Management||Next Page - 5.3 Define Scope|