Fail Master Page

This page is created to help fulfilling the role as Fail Master as efficient as possible. As the role of Fail Master shifts from person to person on daily basis, it is important to share information on findings such that for example Work In Progress tests are evaluated multiple times by various people.

Build Server Test Categorization

This list is the aid the current Fail Master in providing an overview of the the tests that have been categorized. It is there to provide an overview of what are issue to be solved by the Fail Master, which failing Work In Progress tests are due to being targets for future features or future improvements, and which are due to bugs.

Test: Name of the test. Formate is <Test Class>.<Test Method>

Reason/Cause for failure or Work In Progress: Provides an explanation why a test is failing or why the test is set as Work In Progress.

Related Issue: If there is an issue related with the failing test.

Associated Developer: Developer associated with this test. <Developer> is used to indicate that this person has created the test. <Developer> is used to indicate the person is assigned with solving the issue.

Freshness Date: Date when this entry was updated

Related Check-in: Which check-in is related to the test. In italic means it might be associated with this commit. In bold means it is certain this check-in is the cause of the failure.

Test back into production

Some (old) tests have been put in Work In Progress and have been resting here for some time. Some of these tests have proven to succeed consistently for and are potentially ready to be returned in the regular test-environments. These returned tests do need to be monitored closely by the Fail Master in order to be sure that these tests do no turn into "occasionally failing tests", due to various causes such as state-dependency. Any test that has succeeded consistently for 2 weeks in the does not have to be actively monitored any more and can be removed from the following list.