Releasing software with high production level quality, i.e. satisfying end user expectation in terms of functionality and performance, is the final goal of every software collaborative project. Software continuous and effective testing is then a key step in the software development process to match quality targets.
The new testing strategy designed for EMI 3 release should guarantee a more efficient and complete testing activity of the software, eventually resulting in increased product quality and control over the process.
The new approach should allow to shorten the delays experienced in the release process thanks to early identification of the problems occurring at the interface between development and testing, thus resulting in a better coupling of the two activities.
The European Middleware Initiative (EMI) Project has succeeded in merging into a set of releases (EMI 1 Kebnekaise, EMI 2 Matterhorn) more than fifty software products from four major European technology providers (ARC, gLite, UNICORE and dCache). To satisfy end user expectation in terms of functionality and performance, the release process implements several steps of certification and verification. The final phases of certification are aimed at harmonizing the strongly inter-dependent products coming from various development teams through parallel certification paths. This paper introduces the new approach in the design and management of the release process envisaged for the EMI 3 release according to the requirement of a more effective integration strategy emerged during the first two EMI releases.
Integration testing is the part of testing and certification process of a software product where the product pieces of functionality and expected behaviour are tested against other related grid service components. In EMI decentralized software development model, testing and certification are in charge of different Product Teams, each responsible for one or more software components. Taking place after functional testing of products in insulation has been successfully carried out, integration testing then represents the first centralized point of contact among different products.
EMI 1 and EMI 2 releases have shown that many issues were only discovered during the deployment on the EMI phase and that integration testing for EMI-2 was not implemented successfully due to delays in having the testbed in shape since the products were in many cases not deploy-able. The new strategy conceived for EMI 3 release foresees a two steps deployment scenario.
In the first phase the different product teams are responsible of providing and maintaining an instance of their service where the initial testing validation is carried out.
During this phase the SA2 people responsible for the testbed would take care of hosting and configuring a set of "core" services, which lay the foundation of the integration testbed (i.e. voms, top-bdii) that other services will reference during the interoperability and integration testing campaigns.
Ideally, the resources are monitored with a nagios instance hosted and maintained by SA2.
In a second phase of the testing process the services are deployed on the central testbed and a new set of tests is performed centrally as a second independent check.