EMI Inter-component Testing

Note that this twiki contains a draft version of the EMI Inter-component testing phase to be approved by PEB.

Latest approved version of this document
DRAFT

Introduction

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

Workflow

A release candidate is a certified and verified software component that the release manager takes into consideration for the EMI production release. The certification is done by the PT and the verification is done by the QC team.

The release candidate must be installed on the EMI SA2 testbed. The Release Manager must notify the Testbed Manager when a new component is available for installation on the testbed by creating a GGUS ticket for EMI Testbeds.

When the new packages are installed in the testbed, Inter-component tests written by the PTs as part of their Test Plans must be run: the main goal of these tests is to verify the interaction of the installed component with other components. The following questions need to be answered at this stage:

  • Who runs the inter-component tests? Who reports about the result of the tests?
    • If the PTs run the tests:
      • The Testbed Manager has to communicate to the EMT that the Testbed is updated.
      • The component (provider) under test interacts other components (clients). An inter-component test involves one provider component and one or more client components. Hence, there will be a PT provider and one or more PT clients. Who leads the inter-component testing?
        • The PT(s) owing the client components. This approach makes sense because the PT client knows the necessary tests to run and is also responsible for maintaining these tests. With this approach it is also possible to distribute the effort in cases where a single component has many clients (e.g VOMS).
        • The PT providing the component under test. This approach implies that the PT providing the component knows about other components tests and how to run them.
      • The PTs have to report about the results of the tests. Where? In the GGUS ticket?
    • If the Testbed Manager runs the tests:
      • Clear instructions on how to run the tests have to be given by PTs, as well as the location where the tests are available, etc.
      • The Testbed Manager has to report about the results of the tests. Same questions as before: Where? In the GGUS ticket?
    • If Nagios runs the tests:
      • The number of tests available in Nagios is very low. Will PTs write the Nagios probes? Otherwise, who will take care of this?
      • The Release Manager can automatically monitor the results of the tests. This is the approach that requires less effort to run inter-component tests. On the other hand, requires time from PTs to write the probes and effort from the Testbed Manager to maintain the Nagios infrastructure.

The Release Manager should coordinate and establish the deadlines for the Inter-component testing phase by discussing with all interested parties taking into account the release schedule: Testbed Manager, Provider PT and Client PTs. It has to be defined:

  • Expected date for the testbed to be updated with the new components.
  • Expected date for the inter-component test results.

The Inter-component matrix produced by JRA1 has to be made available to the Release Manager so that she can contact the PTs when needed to schedule the inter-component testing phase.

Logbook

  • 21st February 2011: first draft by Gianni.
  • 11th March 2011: Reorganisation of the document + more details by Maria.


This topic: EMI > WebHome > EmiProjectStructure > SA2 > SA2-internal > TSA22 > SQAP > EmiSa2CertTestPolicy > EmiIntegrationTests
Topic revision: r4 - 2011-03-11 - MariaALANDESPRADILLO
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback