# Authoring Test Scripts (Validation Management) Validation Management provides a collaborative and intuitive user interface to help validation professionals author, review, and pre-approve test scripts before they can become available for execution by Executors. The interface allows Test Authors and Test Co-Authors to simultaneously add, copy, and delete setup steps and execution steps to ensure that applicable requirements are challenged effectively. Test Authors and Test Co-Authors can link _Requirements_ to test steps which helps with the automatic creation of the requirements traceability matrix. ## About the Test Authoring Interface {#test-authoring-interface} When you perform the **Author Test** action on a test that is in the _In Authoring_ lifecycle state, Vault takes you to the Test Authoring Interface. ### Test Header This section includes the _Test Script ID_ if available or the _Name_ with the _Title_ of the test script being authored. If the test name and title are too long to display, you can hover over the header to view the full name and title. ### Step Navigation Panel The navigation panel on the left side of the interface allows you to select either the Step View or Requirements Burndown View. This panel, along with the requirements panel and the comment panel, adjusts automatically based on screen resolution and browser window size to optimize users' interactions with the panel. You can collapse the panel by clicking () and expand it by clicking (). #### Step View This view displays sections, setup steps, and execution steps of the test script. Clicking on a step or section in this panel navigates your view directly to it in the content panel. You can collapse and expand sections to efficiently navigate through large numbers of test steps. #### Requirements Burndown View This view displays requirements on the associated _Validation Entity_ and allows you to drag and drop requirements onto execution steps that challenge them, linking them to the test step. Once a requirement is linked (challenged) by an execution step, the requirements traceability matrix is automatically updated to reflect this as well. The _Validation Requirement_ cards in this burndown view display their _Risk Level_, _ID_, and _Description_. Requirements in this view may be automatically filtered to a particular lifecycle state [configured by an Admin](/en/lr/50533906/#interfaces). As requirements are challenged by an execution step, the requirement card is removed from the burndown list. Eventually, once all requirements have been challenged, the burndown list should not show any more requirements that need to be challenged. Click the search icon to search for specific _Validation Requirements_. You must escape characters using `\` when executing a search with the following text operators: `AND`, `OR`, or `,`. For example, `\AND`. Click the filter icon to narrow the list of requirements down by _Requirement_ metadata like _Risk Level_, _Category_, _Source_, _Type_, or _Lifecycle State_. Click **Apply** to set the filter options, or **Reset** to remove them. You can also filter by _Requirements_' challenge status: - **Never Challenged for this Entity**: A _Requirement_ record exists on the _Validation Entity_ and has not yet been linked to a _Test Step_. This is the default filter for the Requirements Burndown view if the _Validation Activity_ configuration is not enabled. - **Not Challenged inside Validation Activity**: A _Requirement_ record exists on the _Validation Activity_ and has not yet been linked to a _Test Step_. - **Not Challenged outside Validation Activity**: A _Requirement_ record exists on other _Validation Activities_ within the same _Entity Version_ and has not yet been linked to a _Test Step_. - **Challenged Inside this Script**: A _Requirement_ record exists on the _Validation Entity_ and it is linked to a _Test Step_ in the current Test Script record. - **Challenged Outside this Script**: A _Requirement_ record exists on the _Validation Entity_ and it is linked to a _Test Step_ in a different _Test Script_ record. ### Content Panel The content panel on the right side of the interface is where the primary authoring of the _Test Steps_ takes place. After selecting the Setup Step section or Execution Step section, click **+ Step** to add a new step within the selected section. Each section displays up to 25 steps per page. Within each step section, you can use the actions at the top right of the step card to **Copy**, **Delete**, or **Save** changes to the step. ### Status & Action Bar The top right of the interface includes the save status and general actions. The save status indicates when you have unsaved changes in a test step in the content panel. The **Reorder Steps** action becomes available once you have at least two steps saved in a section, and allows you to reorder steps in a condensed view in the content panel. The **Reload** button allows Test Authors to reload the _Test Script_. ### Taskbar The taskbar displays under the test header and lists the Test Author's assigned task, the associated task instructions, and the task due date. The task due date color changes based on the number of days remaining until the task is due. A green due date means that five (5) or more days are remaining, an orange date means that less than five (5) days are remaining, and a red date means that the task is overdue. The taskbar also displays a _Show More_ or _Show Less_ link and a _Complete_ button. Click the **Show More** link to expand the taskbar to display the full instructions for the task. Click the **Show Less** link to collapse and hide the instructions. The _Complete_ button allows the Test Author to complete their assigned task. The _Complete_ button is not available until test steps are included in the test script and the changes are saved. If configured by an Admin, Test Authors are prompted to provide a verdict and eSignature once they click **Complete** ## Copying Test Scripts {#copy-test-scripts} An Admin may configure an action to deep copy an existing _Test Script_ record in a particular lifecycle state. This action may be named according to the lifecycle state the new _Test Script_ will be transitioned to. For example, the action labeled **Re-Run Test Script** may copy a test script and transition it to the _Pre-Approved_ lifecycle state. In addition, an Admin may configure an action to deep copy an existing _Test Script_ record to a different _Validation Deliverable_. Upon initiating a deep copy of a _Test Script_ from its **Actions** menu, a dialog appears to select a _Validation Deliverable_ or create a new one before clicking **Continue**. If the chosen _Validation Deliverable_ does not share the same _Validation Entity_ as the original _Test Script_, Vault does not copy requirements and warns the user before proceeding with the operation. Vault sends a notification if the operation is successful or fails. When a user copies a _Test Script_, Vault copies all of its test steps, requirements, and any additional prompts to the new record, however, Vault only copies _Validation Requirements_ if the chosen _Validation Deliverable_ shares the same _Validation Entity_ as the source _Test Script_. If an Admin has configured [naming schemes](/en/lr/50533906/#naming-schemes), Vault increases the _Run Number_ value of the new record by one (1) and assigns the same _Name_ upon copying when the source test script's deliverable and the target test script's deliverable are the same. If the source test script's deliverable and the target test script's deliverable are different, Vault generates a new name and the run number begins from the default value configured for the _Run Number_ field. If your Admin has not configured [naming schemes](/en/lr/50533906/#naming-schemes), you must manually update the _Run Number_ of the new _Test Script_. ## Copying Test Protocols An Admin may configure a user action to deep copy an existing _Test Protocol_ in a particular state. This action may be named according to the lifecycle state the new _Test Protocol_ will be transitioned to. For example, the action labeled **Generate New Run** may copy a protocol and transition it to the _Initiated_ lifecycle state. Upon initiating a deep copy of a _Test Protocol_ from its **Actions** menu, a dialog appears to select test scripts. From the dialog, you can select the test scripts to copy to the new _Test Protocol_ record and click **Continue**. Vault then prompts you to select an existing **Validation Deliverable** from the drop-down or create a new one before clicking **Continue**. Vault sends a notification if the operation is successful or fails. When a user copies a _Test Protocol_, Vault copies all of the selected test scripts and their associated test steps, prompts, and requirements to a new record. Vault only copies _Validation Requirements_ if the chosen _Validation Deliverable_ shares the same _Validation Entity_ as the source _Test Protocol_. Otherwise, the user receives a warning message that Vault will not copy the requirements. If configured by an Admin, Vault only copies requirements in a specific lifecycle state to the new _Test Protocol_ record. The deep copy operation also creates equivalent _Requirement Traceability Matrix_ records according to the linked requirements and test steps of the copied test scripts. If an Admin has configured [naming schemes](/en/lr/50533906/#naming-schemes) and the target deliverable is the same as the source test protocol's deliverable, Vault increases the _Run Number_ value of the new record by one (1) and populates the _Copied From Protocol_ field upon copying. ## Creating Test Scripts _Test Scripts_ contain test steps to be performed by one or more Executors to fulfill a _Testing Deliverable_ for a validation activity. Executors perform test steps in the [Test Execution Interface](/en/lr/50533905/). To create a _Test Script_: 1. From a _Testing Deliverable_ record, navigate to the _Test Script_ section. 2. Click **Create**. 3. Fill in all basic field data, including the **Title** and **Description**. 4. Select a **Test Type**. The options are **IQ** (Installation Qualification), **OQ** (Operational Qualification), or **PQ** (Performance Qualification). If you are creating a _Test Protocol_, you can select more than one _Test Type_. 5. Select whether this test is a **Regression Test**. 6. Fill in a **Run Number**. This value indicates the number of times that the test must be executed either due to a statistical requirement or due to multiple attempts due to discrepancies encountered during execution. 7. Select an **Author**. 8. Optional: Select one or more **Co-Authors**. Users assigned to this role are permitted to simultaneously author test scripts alongside Test Authors. 9. Select a **Lead** **Executor**. 10. If this _Test Script_ was based on another script, select a **Source Script**. 11. Optional: If available, select a value for **Dry Run Required?** This field indicates whether the test requires a dry run before proceeding to pre-approval. 12. Click **Save**. If configured by an Admin, Vault automatically populates the _Record Number_ field with the appropriate [naming scheme](/en/lr/50533906/#naming-schemes). Once created, you can advance the script to the _In Authoring_ lifecycle state, where you can begin [authoring test steps][1]. _Test Scripts_ typically go through a pre-approval review workflow to proceed to a _Pre-Approved_ state. Until the test is _Pre-Approved_, it is not available for execution. However, if configured by an Admin, you may perform the **Start Dry Run** action to [dry run a _Test Script_][6] before its pre-approval and execution. Once a _Test Script_ is in the _Pre-Approved_ state, it becomes available for execution by assigned Executors. At this point, you perform the **Start Test Execution** workflow action to assign roles and begin the test execution process. ## Creating Steps {#creating-steps} To begin test authoring: 1. Navigate to a _Test Script_ record in the _In Authoring_ lifecycle state. 2. Perform the **Author Test** action. 3. From the Test Authoring Interface, proceed with creating [setup steps][2] or [execution steps][3]. 4. Click **Complete** to finish authoring and change the test's state to _In Pre-Approval_. ### Creating Setup Steps {#setup-steps} To create a setup test step: 1. Navigate to a _Test Script_ record in the _In Authoring_ lifecycle state. 2. Perform the **Author Test** action. Vault displays the Test Authoring Interface. 3. In the navigation panel of the Test Authoring Interface, select the **Setup Steps** section. 4. Click **+ Step**. 5. Add a **Step Title**. 6. In the _Prompts_ section, [add or remove prompts][5] as needed. The default prompts for a step are _Procedure_ and _Actual Results_, but each can be removed with the delete icon. 7. In the _Settings_ section, select a value for the **Attachment Setting**: 1. **Attachments Allowed**: Attachments are optional and it's up to the Executor to decide if they want to provide objective evidence. 2. **Attachments Required**: Executors must attach at least one file to complete the step. 3. **Attachments Disabled**: Executors cannot add attachments to the step. 8. Choose whether to allow comments with the **Comment Allowed?** radio button. 9. Optional: Select an **Executor**. If an Executor was defined on the parent _Test Script_ record, Vault pre-populates the _Executor_ field. 10. Click **Save**. When you save a test step, Vault reloads the _Test Script_ if there is no step being edited. If there are other steps being edited, Vault only reloads the saved step. If the _Test Script_ is not up to date, Vault displays a banner to reload the _Test Script_. To add additional steps, you can either click **+ Steps** after the last setup step at the bottom of the content panel, or copy an existing step. ### Creating Execution Steps {#execution-steps} To create an execution test step: 1. In the navigation panel of the Test Authoring Interface, click **Execution Steps**. 2. Click **+ Step**. 3. Add a **Step Title**. 4. In the _Prompts_ section, [add or remove prompts][5] as needed. The default prompts for a step are _Procedure_, _Expected Results_, and _Actual Results_, but each can be removed with the delete icon. 5. In the _Settings_ section, select a value for the **Attachment Setting**: 1. **Attachments Allowed**: Attachments are optional and it's up to the Executor to decide if they want to provide objective evidence. 2. **Attachments Required**: Executors must attach at least one file to complete the step. 3. **Attachments Disabled**: Executors cannot add attachments to the step. 6. In the Settings seciton, choose whether to allow comments with the **Comment Allowed?** radio button. 7. Optional: In the _Settings_ section, select a value for the **Verdict Setting**: 1. **Verdict Required**: Executors must select a verdict (_Pass_, _Fail_, _N/A_) to complete the step. 2. **Verdict Disabled**: Executors cannot select a verdict for the step. 8. Optional: Select an **Executor**. If an Executor was defined on the parent _Test Script_ record, Vault pre-populates the Executor field. 9. Click **Save**. When you save a test step, Vault reloads the _Test Script_ if there is no step being edited. If there are other steps being edited, Vault only reloads the saved step. If the _Test Script_ is not up to date, Vault displays a banner to reload the _Test Script_. 10. Optional: Add [requirements][4] to be challenged by this step. To add additional steps, you can either click **+ Step** after the last setup step at the bottom of the content panel, or copy an existing step. ### Test Step Prompts {#test-step-prompts} You can define up to 15 prompts for each _Test Step_. You can remove prompts with the delete icon. You can choose whether the prompt should extend fully across the step section with the expand and contract icons if it is a text instruction or text response type prompt. Click the copy icon to duplicate a prompt. To reorder the prompts, drag them with the grip icon. The default prompts for a step are _Procedure_, _Expected Results_, and _Actual Results_. If you delete the default prompts, you can bring them back using the **Restore Defaults** button: * **Procedure**: Describes what the Executor must do to complete the step. Click the pop-out icon to view and edit the field in a larger dialog. * **Expected Results**: Describes the expected outcome after completing the step. Click the pop-out icon to view and edit the field in a larger dialog. This is only available for execution steps. * **Actual Results**: An input prompt that allows the Executor to describe the results after testing. Click **Add Instruction** to add an instructional prompt. The available instruction prompt options are: * **Text Instruction**: Additional instructions for the executor. Click the pop-out icon to view and edit the field in a larger dialog. * **Reference Instruction**: An additional reference instruction, such as an image, video, or document.
Click **Add Response** to add a response prompt. The available response prompt types are: * **Text Response**: An input prompt for the executor to provide text. * **Date/Time Response**: An input prompt for the executor to provide a date and time value. * **Number Response**: An input prompt for the executor to provide a numerical value with a unit of measure. ### Demo: Configuring Test Step Additional Prompts {#configuring-additional-test-step-prompts-demo} This video demonstrates how to configure test step additional prompts. [Details](/en/lr/676814/) ### Adding Requirements {#requirements} Execution steps should link to _Requirements_ that they will challenge. Using the Requirements Burndown View, you can simply drag and drop a _Requirement_ onto the _Execution Step_ which challenges it. You can also link requirements to steps manually in either the Steps View or Requirements view: 1. Navigate to the _Requirements_ section in an existing execution step. The _Requirements_ section does not appear until the execution step has been saved. 2. Click **Add**. 3. In the _Filter Requirements_ dialog, select whether you want to view and select from **All** available requirements or filter the list to only requirements that are currently **Not Challenged** by another step. 4. Click **Continue**. 5. In the dialog, select the requirements you want to add. You can further filter the list using the drop-down menus at the top of the dialog to apply a custom filter. 6. Click **Ok**. The _Requirement_ is now linked to the test step. When you add a _Requirement_ in this section, Vault will update the _Requirements Traceability Matrix_ linking the _Requirement_, _Validation Entity_, test script, and test step information. You can change the _Requirements_ section display settings using its **Actions** menu to add or remove columns. To remove a _Requirement_, select it and click **- Remove**. ### Calculating Step Numbers When you add new test steps between existing ones, Vault automatically calculates the step number and assigns it to the _Step_ field. For example, if you add a test step between steps two (2) and three (3), Vault assigns 2.5 to the _Step_ field of the new test step. When authoring a test, rearranging steps can result in _Step_ field values with long decimal values, which could be confusing to Executors. After making changes to the step order in a test, select **Calculate Step Numbers** from the **Actions** menu of the _Test Script_ record to simplify the _Step_ field values to the appropriate integers. This action may be configured as an entry action on _In Pre-Approval_ and _Pre-Approved_ lifecycle states to ensure the step numbers are more readable. ## Dry Running Tests {#dry-run} When viewing a test in the _In Authoring_ state, the **Start Dry Run** action may be available from the record's **Actions** menu depending on your Vault's configuration. You can select one or more **Dry Run Executors** to dry run a script by a **Dry Run Due Date**, in which they can identify scripting errors and provide comments on the test script and its test steps. Upon completion of a dry run, authors can see comments left by the user, resolve or reject feedback, and make adjustments to the _Test Script_ prior to submitting it for pre-approval. Authors and Executors also can filter comments in the Comments View by lifecycle state. When an author initiates a dry run, Vault deep copies the source test script in addition to its test steps and additional prompts, but does not link it to the _Test Protocol_ or _Validation Deliverable_ associated with the source _Test Script_ record. The operation creates a separate set of records for each assigned executor, overwriting the _Executor_ field on the copied test script with the user selected to execute the dry run. Executing a dry run does not increment the _Run Number_ of the source _Test Script_ but copies the value to the dry run test script. Vault notifies the user who initiated the action once all dry run copies have been successfully created, the workflow has started, and tasks have been assigned to the _Dry Run Executors_. ## Reviewing Tests When viewing a test in an _In Pre-Approval_ state, Vault displays the test in a read-only version of the Test Authoring Interface. From here reviewers can review all authored content. Click **Review** to provide a verdict, justification, and eSignature. A rejection verdict may move the test back into an _In Authoring_ state, where the Test Author and Co-Authors can make any necessary changes. The Test Script Review Interface is also available via the **Review Authored Test** action on a _Test Script_ record. ## Generating a Printable View If [configured by an Admin](/en/lr/59106401/), you can execute the **Generate Printable View** action on a _Test Script_ record to display the _Test Script_ and related records in a simplified format. This view can then be printed to a PDF or otherwise via your browser's standard print dialog. This action's label may vary depending on your Vault's configuration. ## Blank Field Value Behavior In test authoring, the following behaviors apply to field values that are blank for any reason: | Field | Functions As | Applicable Step Types | |---|---|---| | Procedure Setting | Procedure Enabled | Setup Step, Execution Step | | Procedure Fit to Width | FALSE | Setup Step, Execution Step | | Actual Results Setting | Actual Results Required | Setup Step, Execution Step | | Actual Results Fit to Width | FALSE | Setup Step, Execution Step | | Expected Results | Expected Results Enabled | Execution Step | | Expected Results Fit to Width | FALSE | Execution Step | ## Related Permissions To use the Test Authoring Interface, users require a security profile and a permission set which grants [these minimum object-level and field-level permissions](/en/lr/50533904/#minimum-permissions): * _Validation Entity_: Read * _Validation Requirement Entity Version_: Read * _Validation Activity_: Read * _Validation Deliverable_ (_Testing Deliverable_ object type): Read * _Validation Requirement_ (all object types including base and custom): Read * _Requirements Traceability Matrix_: Read, Create, Edit * _Test Script_: Read, Create, Edit * _Test Step_ (_Setup Step_ object type and _Execution Step_ object type): Read, Create, Edit, Delete * _Test Step Additional Prompt_ (all standard object types): Read, Create, Edit, Delete * _Unit of Measure_: Read [1]: #creating-steps [2]: #setup-steps [3]: #execution-steps [4]: #requirements [5]: #test-step-prompts [6]: #dry-run