Before You Start: Need-to-Know Information

Role - Admin or User	Description
What is your goal?	To create test result fields and make them available so users can enter data manually, specifically pertaining to performance and measurement.
What happened before this task?	Test Sessions, Test Cases, and other Windchill RV&S Test types may have been created manually or by installing a solution template or running a script to create what was needed. To learn how to set up a document model and the components involved in doing so, see Setting Up Documents.
What do you need to do to complete this task?	See “Creating Test Result Fields”.
What will happen after you complete this task?	The Test Result fields will be listed in Test Result fields node in the Windchill RV&S client.

The performance of test result fields is directly proportional to the number of test result fields being set or updated at any given time. That is, you can define 100 test result fields, but a performance impact is only incurred when users submit results. Test result field visibility is another factor, for example, making ten fields visible on a test result will result in better performance than making sixty visible.

You can set visibility on fields from the CLI using the Windchill RV&S client. This ensures only relevant fields are visible to a particular group.

Inserting new data is faster than updating existing data. For example, creating a new Test Session and Test Case with results against that session, is faster than taking an existing session with existing results and updating it. Online users may not notice an impact from this, but batch users, for example, when calling setresults from an automation script for thousands of test cases will.

where T is the time taken to insert, tc is the number of test cases you are inserting results for and n is the number of test result fields you have populated. As a result, there is always a fixed cost for the number of test cases and a variable cost based on the number of test result fields you populate.

The best practice is to always create a new test session for batch runs and not to re-use an existing session (even if you are re-running the same tests again).

◦ Queries using test results should include additional filters in addition to the test result filters. For example, a query that searches all test results for the value of an integer field will be much slower than the same query with an additional filter on the test case; for example, by project. The test case filter will help narrow down the results so that the, possibly un-indexed, search on the test result integer field will not have as many results to compare.

◦ shorttext test result fields (with the exception of Annotation) are automatically indexed. Amending indexes improves the performance of queries using integer, float, date or pick fields in their clauses. Your DBA should be contacted to create the appropriate indexes in these cases.

• Consider your organization’s needs when determining when to use a test result fields versus an item field on the Test Session or Test case object. Consider when you actually require a test result field vs. a regular field. In order to understand when to use one over the other, you need to first understand the difference between the two and where each are placed in the test application.

What is an item field? Item fields can only be associated with item types. Fields, as generally known in Windchill RV&S, display only on items. In this case, Test Sessions, Test Cases, Test Objectives.

What is a test result field? Test result fields should be used for field that capture additional test result detail, such as measurement or performance details. They are recognized as a Test Result-only field in Windchill RV&S. It is a field that is defined by the administrator for use on test results. Test result fields can only be associated with a Test Result type, of which, there can only be one.