Test Organisation and Approach

A core group of HLT/DAQ developers and testers establishes the planning for the tests which  is discussed with the HLT/DAQ. Sub-system and component specific tests can also be performed. Suggestions are welcome, see howto_participate.

The web page  June 2005 test contains organisational information, details on the testbed and its layout, testbed testing time
schedule of tests and meetings, and the entry to the online test log book. This information is being updated regularly as more details become available.
Currently the core-testers meet regularly every 2 weeks on Thursday mornings. During the tests, more testers/developers join and there short  meetings are held every 2 days on the latest status, to prepare the testing schedule for the next days and to discuss problems where necessary. Everyone involved should participate. Actual information is also communicated via the web page, the log book and a dedicated mailing list. In general, the test cluster is used during the day for system integration, debugging and system tuning while automated tests are run over night. During certain times the PC farm can be shared among the testers (called 'shared mode'). Timing measurements are run in 'exclusive mode', then the use of the PC farm is strictly dedicated to a
particular test only. In the beginning, component and sub-system testing is performed by sub-system
testers and by the component developers. Tests dedicated to study scalability and performance aspects of  software components are also performed.

Once the system is installed,  everyone involved can use the system in shared mode during the preparation week, 6-12 of June . We plan to run through the general series of sub-system tests and complete integration tests during each of the the following  phases in order to eliminate scaling problems as far as possible, understand and optimize the system parameters in use, and adjust the focus of the tests. The last period should be reserved for exclusive  measurements once the integrated system works well on that scale.

A global schedule is being established prior to the start of the tests. However, we have to be flexible. In case of problems with a test, debugging should, if possible, be done elsewhere and another tests which is waiting in 'standby'  takes over. The fine granularity of the schedule will be set in the regular status meetings.

At the end of the tests, a test report is provided similar to the test report from the LST04 tests . Everyone involved participates in the overall part and in providing the part on his/her test description and results.