D4.5.1: Testing and validation – Preliminary
In the context of the SPECS project, one of the problems addressed by the WP4 is the definition of a coherent validation methodology aiming to demonstrate the correctness of the Enforcement module. Moreover, such activity should guarantee that the entire Enforcement module is enough secure to be adopted in SPECS.
In order to be coherent with system level validation approaches, it is not possible to accomplish such validation looking only at Enforcement module. Thus, the concrete objectives of this validation phase are: (1) to build a methodology defining a process by means of choosing the proper techniques to apply, (2) to build a bridge between module-level and system-level approaches, (3) to provide a global improvement to the entire lifecycle of the Enforcement module.
Since the Enforcement module differs from the others by focusing on the security of the SPECS application, a more deep testing analysis is planned and will be performed here. While in the other validation-oriented tasks of the project the stress will be put on different aspects (user experience, functional requirements, interactions among modules), the testing of the
Enforcement module will be also oriented in a way to stress the module under the aspect of security. Hence, this deliverable not only takes into account functional testing techniques but also lists a set of security testing and quality assurance oriented techniques applicable to the Enforcement module: these techniques are well described in particular in the Section 7.2.4 and Section 7.2.6.
SLA-related features also received a special focus in this validation plan. An analysis is present in this deliverable that investigates every single requirement of the Enforcement module related to the SLA management. This analysis, reported in Section 6, reports that the way the Enforcement module deals with SLAs can be reduced to an interrogation on the SLA Manager
component (for detail please see deliverable D1.1.2).
This deliverable is the first release of a series of three deliverables (D4.5.1, D4.5.2 and D4.5.3). While the methodology defined here can be considered quite stable and only some refinements are left over, most of the validation activities will be explored in the next year of the project and reported in the next release of this deliverable.
Deliverable D4.5.2 will include a more detailed specification of the methodology in particular in the procedure of criticality assignment to the component. Another important improvement will be the precise definition of the set of methods and techniques to apply in the testing of Enforcement module.