The SCAS tests, as described in the present specification, are to be applied to a network product whose software and hardware has been brought into use so that the network product can provide the intended functionality, either in a real network environment or in a simulated environment. This implies that, before any testing is performed, the hardware and software has been installed correctly, the network product is powered on, and communication has been established over all standardized interfaces and O&M interfaces related with the network product's functionality, as described in the vendor's documentation. Communication over external non standardized Interfaces that may exist and are marked as optional, according to the vendor's documentation, shall also be established during testing unless they are explicitly marked as "not recommended" in the vendor's documentation. For each of the enabled external communication interfaces there may be various optional capabilities. During testing, all such capabilities shall be enabled unless they are explicitly marked as "not recommended" in the vendor's documentation. In some cases a testcase might require configuration changes as part of the execution steps or pre-conditions. After such test is executed and prior to any further test execution it needs to be ensured that the state of the Product under Evaluation is restored back in the original state. SCAS testing is not about security in operations and deployments. So, in particular, SCAS testing is independent of any network operator guidelines or considerations on specific deployment scenarios.

The following text shall apply to all test cases described in the present document: The present document takes into account that the landscape of testing tools evolves more rapidly than SCAS specifications. It is therefore allowed that, for each requirement, the actual test carried out may deviate from the stepwise description of the test case in the present document if the following conditions are fulfilled:

1. The test is carried out by preferably using Commercial-of-the-Shelf (COTS) and Free-Open-Source-Software (FOSS) tools that are available for other testers that may want to repeat the test. In case a tool not in any of these two categories is used then evidence of the quality assurance of the tool needs to be provided. This applies only to tools used to perform the actual test and not supportive tools needed for setting up the testing environment like for example traffic generators/ simulators.
   In cases where a tester is not able to obtain the necessary tools to perform the test, vendor proprietary test tools may be used by the tester as long the test tool is controlled under a suitable quality management system (QMS). The tester ensures that this QMS is in place in order to avail of a vendor's test tool.
   Additionally in cases where the test lab does not have the necessary test environment to perform a test, it shall be possible for the test lab personnel to perform the test in a vendor's test lab. In such cases the tester shall record details of test environment, test set-up used and how the test was performed.
2. The tester provides evidence, e.g. by referring to the documentation of the tool, that the tool is suitable to verify the requirement, and the scope of testing is equal or larger to the one of the test case described in the present document. The evidence needs to be sufficiently detailed for experts in the field of testing, not for the general public.
3. The tester provides evidence that the tool has been actually used for testing the network product (e.g. by providing a trace).

When a test case makes an assumption on the availability of certain items in the product documentation then this assumption is to be considered part of the requirement even if the requirements text does not mention the documentation.