If an object is edited by two users at the same time, these changes may collide. The following measures are provided for this in the application.

When saving an object, an attempt is made to automatically resolve possible conflicts with concurrent changes as far as possible. Any changes made by other users that do not affect fields that the current user has changed are merged without additional user input.

If field contents have been changed that were also changed by another user in the meantime, a dialog is displayed. There the user can choose how the conflict should be resolved.

Figure 5.28 shows the Conflict Resolution Dialog for a conflicting test case change.

For each conflict, the user has the choice of saving the object with the value they entered or keep the value currently present in the database. For lists, e.g. the list of test steps in a test case, the user has the option to Merge the changes or to keep the version which is currently in the database. This is to prevent the inadvertent loss of data through the deletion of objects which were added by other users.

The Merge option builds a list containing all the elements of both lists (user input and database) in an approximation of the correct order.

Clicking the Save button persists the selected changes to the database, while clicking the Discard button discards them.

Properties and user defined properties ( Section 5.2.3.2.4, “User Defined Properties”) can be referenced and resolved in the displayed text fields while executing jobs, test cases or test suites. For example, the following test case precondition references the system under test in which it is executed:

"Please ensure that the operating system version in /config/os matches %sut:buildnumber% before executing this test case."

When executing this test case, %sut:buildnumber% gets replaced by the value of the user defined property buildnumber of the system under test for which the test case is executed. So assuming the value for the property is 1.44_alpha3, the text will be output as follows:

"Please ensure that the operating system version in /config/os matches 1.44_alpha3 before executing this test case."

Property substitution is supported both for the common pre-defined attributes of an object (e.g. the name or id) and the user defined properties. The name of the common attributes can be derived from the corresponding bean methods defined in the de.verit.klaros.core.model .

Properties of the following objects are currently supported:

Assume that the following example text is used in the test case precondition:

"Please make sure that your system under test is using version %sut:productversion%."

The attribute name productversion is found in the class documentation for the SUTImplementation class in de.verit.klaros.core.model.KlarosSUTImplementation. Given that the version defined there has a value of 1.0.1, the following output will be rendered when displaying the precondition:

"Please make sure that your system under test is using version 1.0.1."

Similar to referencing user defined properties in test case and test case steps ( Section 5.3.3, “Referencing Object Properties”), values from binary attachments can be referenced as well. Currently, CSV and XLS files are supported.

Binary attachments of the following objects are currently supported:

In addition to the above, the global wildcard att can be used. The position of the attachment is thus not specified. In this case, all objects involved in the test execution are searched for the attachment.

A placeholder can be defined in the form %[object type]:[file name]:[column]:[row]% using the following parameters:

The file name, column and row parameters can also be defined using user defined properties. So %itr-att:customers.csv:%job:Customer%:%job:CustomerNr.%% references the attachment customers.csv of the current iteration, using the value in the column defined in the attribute Customer of the current job and the row defined in the attribute CustomerNr.