4.4. Scope of testing
In this topic, you will consider who is responsible for testing which areas so that all of the stakeholders are on the same page about the scope of testing before testing is conducted.
The scope of testing pictured by each stakeholder will vary if the system being tested is linked to external systems or if only part of a system is being modified in the project.
If the stakeholders are not on the same page when testing is conducted, issues like the one below may occur during the process, with the result that it may not be possible to meet the QCD targets of the project.
- In the past, stakeholders have deemed testing insufficient after the test cases were created and the tests were conducted, as the scope of testing was different from what they pictured. As a result, unplanned tests had to be added.
Overview of points to be considered
Establish which features and interfaces will be tested, and which will not and then confirm the overall scope of testing.
You will need to confirm the scope of programming and configuration (scope of development) for your project using materials such as the requirement definitions before making considerations about this.
Relationship between this topic and other topics in the overall test plan
This topic is mainly related to the following topics as shown below.
Relationship between this topic and other topics
- Identify features, interfaces and other elements to be included in the scope of development and determine which of these should be included in the scope of testing. In most cases, all of them will be included in the scope of testing.
- Consider whether any points outside the scope of development need to be included in the scope of testing.
- If products or OSS from external vendors will be included, these may be included in the scope of testing to a limited extent, e.g. only the components that will be directly used within the scope of development.
- As a general rule, any components that may be affected by the development, such as unchanged areas in maintenance or maintenance development, should be included in the scope of testing even if they are not within the scope of development.
- If any of the features, elements or other elements that have been identified so far are outside the scope of testing, clearly indicate these along with the reason.
- The usual reason for this is that while these elements may be affected by development, testing is omitted for reasons related to cost, quality targets or other constraints.
- Indicate which points are within the scope of testing and which points are outside it and check for contradictions between this and materials or decisions related to the scope of development (RFP, proposals, requirement definitions, etc.)
- Make a diagram indicating the boundaries of the scope of testing that has been decided so that everyone can understand what is within the scope and what is outside it.
- The boundaries should be clearly indicated in cases where there are multiple elements interacting with the elements covered by the scope of development, such as those where the system will be linked to other systems or where there is an existing system.
- A diagram is not needed for small-scale tool development where there is no linking between systems and the scope of testing is easily recognizable.
Measures such as listing the features being tested should still be taken to ensure that the stakeholders are on the same page.
Points to consider when considering which elements should be tested and which should not
Consider the following points when making this distinction.
- The scope of development
- Other programs and systems that are linked to elements within the scope of development
- Libraries and tools used by programs within the scope of development
- In the case of a package customization project, the part of the base package that is necessary for the operation of the development scope and the part that may be affected
- In the case of maintenance and maintenance development, those parts of the base system that are necessary for the operation of the development scope and those parts that may be affected
- If any components will be tested by personnel outside the project team, the scope of testing by these personnel must also be clearly indicated so that the stakeholders are on the same page.
- This is to avoid situations in which nobody tests some components because each party thinks that the other will conduct the test.
- If any changes that affect the scope of development are made after starting development, such as adding features for development due to specification changes, the scope of testing needs to be revised too.
- If the content of the project will be released in stages and the test phases are divided accordingly, clearly indicate the scope of testing for each release.