WHAT IS A MET?
A MET is a structured set of tests covering most Etere modules. These tests are executed whenever a major Etere version (for example 34, 35, 36, etc.) is about to be released.
The purpose of a MET is to verify that a specific Etere version - which up to that point has been considered a Release Candidate - behaves as expected and is therefore ready to be officially released as a Release.
A MET may also be limited to Etere modules that rely on Medialooks functionalities. When Medialooks releases a new version, the corresponding DLL files are integrated into a new Etere release candidate. This release candidate then becomes the target of the MET. In this case, the number of tests is smaller and only modules involved in playout, recording, preview, transcoding, and similar functionalities are included.
WHO PERFORMS THE TESTS
The tests are assigned by Laura to all members of the Support Team. They have to be carried out during periods of the day when there are no support tickets to handle.
A MET is usually assigned between late November and early December. Since the release of a major Etere version typically occurs during this timeframe, the deadline is generally set to either December 25th or December 31st.
WHERE TO FIND MET TESTS
In the past, the Support Team used a dedicated internal tool that collected all MET tests. This tool allowed testers to read test descriptions, record results, and open incidents in case of issues.
Currently, MET tests are implemented as a series of support tickets, created by Maurizio through a dedicated procedure. Once the MET has been created, Maurizio notifies the Support Team, Fabio, and Laura via email, specifying the name and version of the MET to be executed.
To view the list of MET tests, follow this procedure:
1. Open Advanced Search
2. In the MET filter, select the MET indicated by Maurizio
3. By default, incidents are sorted by ticket code; however, it is recommended to sort them according to the execution order. To do so, select Priority Asc in the Order parameter.
4. It is also recommended to display the full list, by selecting All in the Show filter.
HOW TO EXECUTE A MET
To perform MET tests, a new database is generally used. This database must be configured before starting the tests and should include the MET version in its name so that it can be easily identified (for example: MET_v40_Etere35.2). However, if the time available to complete the MET is limited, an already configured database may be used.
As for the machine on which Etere is installed and the tests are executed, the SGS8 server hosts dedicated virtual machines. However, these machines cannot be used for tests that require specific hardware installed on the system, such as SDI-based playout tests. In such cases, the Support Team uses one or two physical machines equipped with the required SDI cards.
The test database, the test machines, and the Etere version to be used must all be selected before starting any MET test. The chosen Etere version must remain the same throughout the entire MET, unless a developer provides a fix specifically related to one of the tests that have already been executed.
It is important that this information is documented in the first incident in the MET list. This incident is linked by default to all others, ensuring that the information is easily accessible regardless of which test is being performed.
Once these preliminary aspects have been defined, the actual tests assigned by Laura can begin.
MET TICKET STRUCTURE
When reviewing the list of MET tickets, it is possible to see that they are organized into sections:
met_structure
Incidents with *** in the title act only as section separators. They are not actual tests and should be closed only once all tickets belonging to that section have been completed.
Before testing Etere modules, the installation and configuration steps - described in the first sections of the list - must be completed.
As with internal fix testing (see chapter 3.4.0.0 How to Test a Fix), if a test is successful, the corresponding ticket should be closed. If the test fails, the issue must be analyzed and, if necessary, reported to the relevant developer.