EMI Inter-component Testing Policy (DRAFT)

This page collects a draft policy for executing Integration Tests of the EMI middleware components. At the moment, this is a very first draft whose main point is to highlight the decisions to be taken. A list of open questions are highlighted in bold.

Proposed approach

Integration tests are tests involving more than one EMI software component, and may require the involvement of more than one Product Team (PT). The complexity of coordinating and executing these tests varies depending on the components to be tested. Integration tests must be done always after certification and before releasing a component in the production environment.

When a new software component is certified, this has to be installed on the EMI SA2 testbed. The Release Manager must notify the Testbed Manager when a new signed component is available for installation on the testbed. (Q1: Who signed the packages? How?)

When the signed packages are installed in the testbed, some tests should be run: the main goal of these tests is to verify the interaction of the installed component with other components.

To help the analysis, let's call provider the component under test, and clients the components that interact with the provider. An integration test session should involve one provider component and one or more client components. Hence, there will be a PT provider and one or more PT clients. A first possible approach is to give the responsibility of running the tests to the PT(s) owing the client components. This approach makes sense for the main reason that the PT client knows best which are the necessary tests to run, and it is also responsible for maintaining these tests. With these approach it is also possible to distribute the effort in cases where a single component has many clients (e.g VOMS).

Some or all the tests to be run can also be run automatically through Nagios. However, at the moment, the number of tests available in Nagios is not enough to cover all the integration needs. Therefore, effort for running manual integration tests should be accounted for by each PT.

The integration test period should be agreed between all the interested parties: Release Manager, Testbed Manager, Provider PT and Client PTs. In any case it should not last more than 1 month.

At the end of the integration test period, the client PTs should publish the results of the tests (Q2: Where? As appendix to the test report of the provider component?). If all the tests run are successful, the provider component can be release to production.

In order to follow this approach, each PT should prepare a list of components for which the PT will act as client during integration tests. This list has to be made available to the Release Manager so that he/she can contact the PT when needed to schedule an integration test period.

Change history

  • 21 February 2011: first draft

-- GianniPucciani - 21-Feb-2011

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r3 - 2011-03-02 - MariaALANDESPRADILLO
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback