--- title: "Scripts" canonical: "https://docs.getxray.app/space/XRAYCLOUD/44565563/Scripts" format: markdown --- ![image](media://7aee25d4-b35d-4c7f-9fab-fa9a788c3cb0) > Macro (ui-expand) > > > Macro (toc) # Introduction Scripts allow you to define the Steps and expected results for your [Scenarios](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565557). They provide clear instructions for Testers or automated frameworks, ensuring consistency in how scenarios are executed and making your tests more reliable and well-documented. Since these scripts are data-driven and are based on a [Test model](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565545), they are more maintainable. Adding or removing [Parameter values](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565547), constraints, or forced interactions in your model updates the Scenarios data driving the Scripts, but there is often no need to adjust the script details. You can quickly transform optimized Test data, as depicted in Figure 1, into customizable scripts (Figures 2 and 3). ![Figure 1 - Scenarios Data](media://dce545c7-38c4-4de2-a104-9a6e5d67e84d) ![Figure 2 - Manual Scripts](media://4571145f-a3c8-47ba-8ef3-e82a3d06d995) ![Figure 3 - Automate Scripts](media://4b8b538b-5262-45e4-8294-8666a1701559) # Operations ## Accessing the Scripts > Macro (rw-ui-steps-macro) > > > Macro (rw-step) > > To access this feature, open a model - e.g., click *My Test Models* (Figure 4 - 1). > > ![Figure 4 - Open Test Model](media://6be18260-baed-4cf8-bb91-426854b6a75f) > > > Macro (rw-step) > > Click any of the models (Figure 4 - 2) - or create a new one. > > > Macro (rw-step) > > A menu will appear on the left. There, click *Scripts* (Figure 5 - 1) and select one of the two options: *Automate *(Figure 5 - 2) or *Manual* (Figure 5 - 3). > > ![Figure 5 - Scripts menu navigation](media://fcc10feb-2231-411b-bccc-16974300e4b0) ## Automate Automate (Figure 5 - 2) is a smart [Gherkin](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565320) feature file editor. It is “aware” of the [Parameters, Values](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565547), and generated Test cases of the current model as well as the Gherkin syntax, with highlighting and autocomplete features. Automate makes it easy to create a feature file with data-driven Scenario and/or Scenario Outline sections that are populated by the generated test cases of your model. > ⚠️ We’ll try to make the distinction between the Scenarios screen, with its scriptless data table, and the Scenario/Scenario Outline options of Automate scripts as clear as possible. ### Working on an Automate Script #### Top Ribbon > Macro (rw-ui-steps-macro) > > > Macro (rw-step) > > Work on your Gherkin feature in the editor panel on the left (Figure 6 - 1), and the generated Scenario sections or Examples data tables are shown in the preview panel on the right (Figure 6 - 2). > > ![Figure 6 - Top ribbon functions in Automate](media://8d13ed1b-deb3-4db0-a062-ce9a9a341295) > > > Macro (rw-step) > > Once you're done editing, click the *Save* button (Figure 6 - 3). This button will become active as soon as you make a change in the text field (Figure 6 - 1). > > > Macro (rw-step) > > You must generate Test cases (Scenarios data table) first before the preview becomes active, then select the appropriate strength (Figure 6 - 4).  > > > Macro (rw-step) > > You can click the *Usage* button (Figure 6 - 5) for a refresher on the Automate functionality. #### Feature and Background Each Gherkin script has a Feature as its first keyword, followed by *:* and a little bit of context to describe the scope, usually in the form of a user story (which is demonstrated in the placeholder text). **This section does not support parameterization of any kind.** A Background section is useful when a set of initial setup steps is repeated before each Scenario and Scenario Outline in the feature file. Starting a new line in Background and further sections brings up a suggestion dialog with standard Gherkin keywords. Keep in mind that restricting a parameter in the Background (with *{[]}*, as explained in the Conditional Logic section below) is valid syntax and is used to apply only the selected value to all Scenarios or Scenario Outlines for a given Feature. #### Scenario or Scenario Outline Next in the feature file is the enumeration of different Testing Scenarios. One way to describe a Test case is with a Scenario block. It contains sequential steps, expressed as plain English *Given/When/Then* statements, that describe the necessary actions for executing the automated Test script. If the model generates 28 rows on the Scenarios screen, then you could think that 28 Gherkin Scenario sections would need to be written out to achieve the combinatorial coverage. However, instead of writing out all 28 scripts individually, you leverage Automate to create a single data-driven Scenario that includes the ** syntax. Then the tool can generate all 28 needed Scenario sections in the **exported** feature file. You can check the number of associated Test cases in the Preview panel (Figure 7 - 1). ![Figure 7 - Scenario block example in Automate](media://ad333fb5-9adb-4a00-bfd2-bf947fb7a31e) A Scenario Outline behaves similarly to a data-driven Scenario. When using a Scenario Outline, instead of having 28 Scenario sections (one for each Test case), the export has one data-driven Scenario Outline with a Gherkin Examples data table attached to it that contains 28 rows (again, one for each Test case). The Preview panel shows the first 10 rows of the Examples data table (Figure 8 - 1). **The order of Parameters in the Examples is dictated by the script, not by the Parameters screen of your model.** ![Figure 8 - Scenario Outline block example.png](media://69bb123c-8b07-401d-b7e7-6d58d98f23a2) > ⚠️ Where possible, using Scenario Outline sections is preferable to generating many data-driven Scenario ones, as Outline is a more compact expression of the Testing ideas of the model. The basic principles of your work with an Automate script are similar to those in any other Gherkin text editor. Click the grey background in the left panel to edit the script's text and write anything you want. You can phrase the actions however you’d like and utilize any combination of Gherkin keywords. With that said, (in most cases) **you must connect Scripts to the Scenarios table via the parameterized syntax.** Simply typing < will populate a list of autocomplete suggestions related to all of the parameters in the model. At the end of the list, we have system variables: - Test Number (sequential number **within** the Scenario script block). - Test Case (constant number of the row in the complete table on the Scenarios screen). - Expected Outcome (from the Forced Interactions screen, if applicable). Wherever the ** appears in the Test Steps, it will be replaced by the specified Parameter's value for the corresponding test case. For example, writing the step: > And they select for the car's color means that in each generated Scenario script block, the ** portion of the step will be replaced with the value of the Color parameter for the corresponding Test case: > And they select Deep Blue Metallic for the car's color       or > And they select Red for the car’s color       etc. > ℹ️ It is common to put dynamic elements in quotes (e.g., *And they select "" for the car's color*) to make them more visually distinguishable. As you insert Parameters into the script, they will become greyed out in the dropdown you get from typing *<*. It’s a quick way to check that you haven’t accidentally omitted any important variables by the time the script is finished. ### Reusable Steps > Macro (rw-ui-steps-macro) > > > Macro (rw-step) > > You can make a step reusable in other scripts by clicking the "+" button that appears to the left of a Gherkin step (Figure 9 - 1; the line must have an indent). > > ![Figure 9 - Saving a step as reusable](media://c4b5efd6-496e-4d4f-ab3f-dd01b3fb8a73) > > > Macro (rw-step) > > If the current Test model is in a project, you will be prompted to select whether the step will be reusable within that project only or for every Test model in your organization (Figure 10). > > ![Figure 10 - Convert.png](media://0ee94ff9-2a84-460e-8744-9e13bc0f9de0) > > > Macro (rw-step) > > You will see a confirmation (Figure 11). > > ![Figure 11 - Confirmation](media://47fa2c86-01ae-4de5-b7fe-ab2bda3afba7) > > > Macro (rw-step) > > To leverage reusable steps, simply start typing on a step line in any Gherkin feature file. Automate will show matching reusable steps in the autocomplete dropdown as you type (Figure 12 - 1). > > ![Figure 12 - Inserting a reusable step](media://86b48861-80ca-4a13-9502-c47d21d6d16d) > > > Macro (rw-step) > > Select the desired step from the list, and its content will be inserted at that position. Reusable steps can include parameters using angle bracket notation (e.g., **), just like regular steps. Reusable steps can also include value conditions (e.g., *{State[West Virginia, Pennsylvania]}*). > > > Macro (rw-step) > > You can access the library of reusable steps by opening the model properties menu (click the model name at the top) and selecting the *Automate Reusable Step Library* menu item (Figure 13 - 1). In the library, you can see the list of steps, when they were created, when they were last used, and who created them. > > ![Figure 13 - Automate Reusable Step Library menu](media://5dbe54d6-aa00-4cb9-b364-b09204472d48) > > > Macro (rw-step) > > You can edit a reusable step from the library by clicking the step's name or the pencil icon (Figure 14 - 1). The name is the content that gets inserted when the step is used. You can press the *Enter* key to save the changes or *Esc* to cancel them. You can also delete a reusable step here by clicking the trash icon (Figure 14 - 1). > > ![Figure 14 - Automate Reusable Step Library.png](media://790cc4ac-9093-45a1-bc2b-fb63f91c655c) > > > ℹ️ Editing a reusable step affects its content for all future uses. However, existing scripts that have already used the step won't be affected by the change. ### Conditional Logic Oftentimes, application flows may have more or fewer steps that need to be executed for specific Test cases. For example, in Tesla's car configurator, if the user is configuring a new Tesla Model S, there is no option for the Interior Layout.  Let’s say the Test model for the Tesla car configurator contains a bi-directional bound pair constraint tying *Model = Model S* and* Interior Layout = N/A* together. If you don’t do anything else and just pass ** and ** to an Automate script, some Test cases will read: > And they select the N/A Interior Layout While you could figure out what this means in manual Testing or set up an extra code snippet in automated Testing, it’s a bit suboptimal. Automate provides a way to restrict a Scenario or Scenario Outline to Test cases that contain a specific value using the *{Parameter Name[Parameter Value]}* syntax. Simply typing *{* will populate a list of autocomplete suggestions related to all of the Parameter values in the model. ![Figure 15 - Example of a conditional restriction](media://46275dc0-5c29-4153-9d4b-1582415f1c96) Including *{Parameter Name[Parameter Value]}* anywhere **in the set of steps** in a Scenario or Scenario Outline will restrict the Test cases included in the generated Scenario blocks or Examples data table to only those that contain the specified Parameter value. So, for instance, you would create 1 Scenario block with *{Model[Model X]}* and with the Interior Layout step + 1 Scenario block with *{Model[Model S]}* and without the Interior Layout step. As mentioned earlier, if all script blocks within an Automate tab follow the same conditional logic, you can restrict all of them in one action by using the *{Parameter[Parameter Value]}* syntax in the Background section. You can have more than one value per restriction: just separate them with commas. It is also possible to invert a restriction by adding an exclamation point just after the opening curly bracket, like so - *{****!****Parameter[Value 1, Value 2]}* . This includes all the Test cases in which "Parameter" is **not** "Value 1" or "Value 2". > ⚠️ Please make sure that you cover all the generated rows from the Scenarios screen across the Value Restrictions, especially if you leverage multiple Automate tabs. ### Multi-tab Approach Each script tab in Automate corresponds to one FEATURE file (or one CSV file for transitions to certain Test management tools like Xray).  An Automate tab can contain as many data-driven Scenario and/or Scenario Outline sections as needed to automate all the Testing ideas and flows contained in the Test model. For the avoidance of doubt, you can mix Scenario and Scenario Outline blocks on the same tab. Sometimes, putting all your script blocks on one tab can be overwhelming. Or one of the flows is not yet ready for execution, so you don’t want to mix it with the others for export purposes.  ![Figure 16 - New Automate script](media://1719dcef-d785-443a-957f-17d1eea2b68e) You can create multiple tabs in Automate by clicking the *+* icon in the top ribbon (Figure 16 - 1), providing a unique name (Figure 16 - 2), selecting the type (Figure 16 - 3), and clicking *Create* (Figure 16 - 4). When you click on any tab, you can click the pencil icon to edit the script's name, the trash icon to delete the script, or the copysheet icon to clone the entire tab. When you export into *Gherkin Feature File* or *Automated Test Framework*, you will have an option to select all scripts or only the specific ones. ![Figure 17 - Automate script export](media://bd273431-2d0f-469e-aeaf-267bd02d9ced) ## Manual Manual (Figure 17 - 3) is a script editor in a grid format. It is aware of the Parameters, values, and generated Test cases of the current model. Manual makes it easy to create a CSV file with data-driven Action/Data/Expected Result sections - export will generate a script per Scenarios row, based on your Manual template structure. ![Figure 18 - Scripts menu navigation](media://2a0d0a85-e8a3-4bcd-8293-2968a0801eba) ### Working on a Manual Script The basic principles of working with a manual script are similar to those used in Test management tools. #### Top Ribbon > Macro (rw-ui-steps-macro) > > > Macro (rw-step) > > Work on your step content in the editor grid (Figure 19 - 1). > > > ℹ️ To save the whole script, you need to use the *Save* button at the top (Figure 19 - 2). I.e. *Done* from each step does **not** auto-save the whole tab. > > ![Figure 19 - Top ribbon functions in Manual](media://04b1711d-914e-4275-8f38-f85795f2fc46) > > > Macro (rw-step) > > When you have unsaved changes, the *Discard* button appears next to *Save* (Figure 20). It reverts the script to the last saved point. > > ![Figure 20 - Buttons](media://86ab2797-433e-4297-bb54-ab6ffcdbdcd9) > > > Macro (rw-step) > > Below the tabs (Figure 19), you can select one of the generated Scenario strengths and the specific Scenarios row to control your preview for the value replacement throughout the script (Figure 19 - 3).  > > > Macro (rw-step) > > You can click the *Usage* button (Figure 19 - 4) for a refresher on the Manual Scripts functionality. #### Step Content > Macro (rw-ui-steps-macro) > > > Macro (rw-step) > > To define your steps, click the grey background in the row (e.g., between the words *Action* and *Data; *Figure 21 - 8) and provide the necessary text. The template format includes columns for *Action, Data, and Expected Results*. This selection is not customizable, but you only need to provide input in one of the three columns for a step to be saved. You can phrase the content of all three columns however you’d like. With that said, (in most cases) **you must connect Scripts to the Scenarios table via the Parameterized syntax.** > > ![Figure 21 - Editing](media://8b308917-f2fc-4b87-80e1-f53bde84d3c5) > > > Macro (rw-step) > > Simply typing *<* will populate a list of autocomplete suggestions related to all the Parameters in the model (Figure 21 - 1). For example, writing the step: > > > User selects for the car's color > > means that in each generated Manual script (in preview or export), the ** portion of the step will be replaced with the Value of the Color Parameter for the corresponding Test case, such as: > > > User selects Deep Blue Metallic for the car's color > > or > > > User selects Red for the car’s color > > etc. > > Parameterized syntax can be used in **any of the three columns**. The same Parameter can be used multiple times in the same template. It is also possible not to use all the parameters in a given template.  > > > Macro (rw-step) > > Once your step-level edits are complete, you can click *Cancel* or *Done* (Figure 21 - 2). > > > Macro (rw-step) > > As you insert Parameters into the script, they will become grayed out in the dropdown you get from typing *<*. It’s a quick way to check that you haven’t accidentally omitted any important variables by the time the script is finished. > > Within a tab, you can: > > - Copy individual cells within the tab or across tabs (Figure 21 - 3; e.g., hover over *Action* and click the copy sheet button that appears next to it, then paste elsewhere with Ctrl + V). > - Clone the entire step (all three columns + conditions, if any) by clicking the copy sheet button located on the right side of each step (Figure 21 - 4). > - Delete individual steps by clicking the trash bin button located on the right side of each step (Figure 21 - 7). > - Reorder steps by dragging them (six-dot icon) or clicking corresponding arrows located on the left side of each step (Figure 21 - 5). > - Hover over a white space around an existing step and click *New step* to insert it directly into the desired place (Figure 21 - 6). > > > ℹ️ The Relax feature has been removed (at least for now). So, to recreate its behavior, you would need to manually clone the steps and change the Parameter syntax and references. #### Reusable Step Blocks You can save all the steps of a manual script as a block of steps that can be reused in other scripts. > Macro (rw-ui-steps-macro) > > > Macro (rw-step) > > Click the *Save for Reuse* (Figure 22 - 1) button. You are then prompted to create reusable step blocks for just the current project or for everyone. > > ![Figure 22 - Save](media://36cecf2c-594e-474d-8062-292584abd4ce) > > > Macro (rw-step) > > To use a block, you can open any Manual Scripts tab, then click *Reuse Step Block* (Figure 22 - 2). Select the desired block from the dropdown, and its steps will be inserted at that position. > > > Macro (rw-step) > > You can access the library of reusable blocks by opening the model properties menu (click the model name at the top; Figure 23 - 1) and clicking the menu item *Manual Reusable Step Library* (Figure 23 - 2). > > ![Figure 23 - Model](media://e03453a1-a261-4d4f-a669-3c188e7653a3) > > > Macro (rw-step) > > In that library, you can see the list of blocks, the number of steps they contain, when they were created, when they were last used, and who created them (Figure 23 - 1). > > You can edit a block from the library by clicking the block's name (Figure 23 - 2). The block will open in the model you have active, meaning that blocks are not tied to only the model in which they were created. Editing an existing block affects its content for all future uses, so be mindful of uncoordinated changes that may only apply to some use cases. Existing models that have already reused the block won't be affected by a change. > > ![Figure 18 - Block](media://45426f74-4166-41f6-96b6-9ccee5667d31) > > > ℹ️ If a model that originated the block is deleted, the block still remains in the library. ### Conditional Logic Oftentimes, application flows may have more or fewer steps that need to be executed for specific Test cases. Step Conditions are the backbone of making sure your Manual Scripts accurately reflect the Scenarios.  > Macro (rw-ui-steps-macro) > > > Macro (rw-step) > > If a specific behavior doesn't apply to every Test case, when you edit a step, you can click the *+* icon (Figure 25 - 1). You can then specify the Parameter value (or combination of them - just click *+* again) that would control whether the **whole step **(all three columns) will appear in the exported script for a given Scenarios row.  > > ![Figure 25 - Conditional steps](media://1487b3e5-57fd-44b8-9a08-4d4dd109cb80) > > > Macro (rw-step) > > We’ll use the same example as in the Automate section - in Tesla's car configurator, if the user is configuring a new Tesla Model S, there is no option for the Interior Layout.  > > > Macro (rw-step) > > We set the condition to the ** Parameter being not equal to “Model S” while editing the step (Figure 25 - 2). Then click *Done*, and the color of the conditional step will reflect its applicability to the Test case number you selected for preview (Figure 19 - 3): > > - Green (Figure 25 - 3) means that this step will appear in the export for the particular Test case (when that Test has a Model different from “Model S”). > - Red with the crossed-out condition (Figure 25 - 4) means that this step **will NOT appear in the export** for the particular Test case (when that Test has “Model S”). > > > ℹ️ For the avoidance of doubt, the color of the same step will change based on the preview - the image above just collates different states together, but (Figure 25 - 3) and (Figure 25 - 4) are mutually exclusive and won’t show as duplicated step entries. > > > Macro (rw-step) > > If you have the same Action that can have different, value-dependent expected results, you have to create **a step for a unique expected result**, explicitly adding all condition combinations at the step level. Then, hardcoding the corresponding expected result in each step (see a few more tips in the *Nuances* section below).  > > You need to specify the minimum number of Values that will result in the step being applied or the expected result being triggered (i.e., if Expected Result XYZ appears for A1 + B1 + ! and A1 + B1 + #, and the third parameter only has those two values, then your Condition is only A1 + B1). > > > ⚠️ Please make sure that you cover all the generated rows from the Scenarios screen across the Step Conditions (especially if you leverage multiple Manual tabs). #### Multi-tab Approach Each tab in Manual corresponds to one CSV file for transitions to certain Test management tools and contains one script template. Each Manual script template can include as many steps as you need. Although if you feel like the count becomes unmanageable, it can be a sign to split the script and/or the model. Sometimes, putting all your script variants on one tab can be overwhelming. Or one of the flows is not yet ready for execution, so you don’t want to mix it with the others for export purposes.  > Macro (rw-ui-steps-macro) > > > Macro (rw-step) > > You can create multiple tabs in Manual by clicking the *+* icon (Figure 26 - 1), providing a unique name (Figure 26 - 2), and clicking *Create* (Figure 26 - 3). > > ![Figure 26 - New Manual script tab](media://b8de53c0-c6b9-4e6f-ac0e-96bea17a7130) > > > Macro (rw-step) > > When you click any tab, you can click the pencil icon to edit the script's name, the trash bin icon to delete the script, or the copy sheet icon to clone the entire tab.  > > > Macro (rw-step) > > You cannot save an empty tab, so if you want to reset the script after the tab has been edited, you will need to delete the tab.  > > > Macro (rw-step) > > When you export into a Test management tool, you will have an option to select only the specific ones. > > ![Figure 27 - Manual script export](media://716a8724-e83b-459b-8fac-6823e75f582a) > > > Macro (rw-step) > > You can now use the *{scenario_name}* name variable in the export of Manual scripts; it represents the tab name. > > > ℹ️ There is an extra option in the script selection dropdown (for exporters that support Manual Scripts). It’s called *Simple Parameters Script*, and it exports a step per parameter in the “Parameter Name = Parameter Value” format. It requires the Manual Scripts to be empty. If you just want to quickly move Scenarios into a Test management tool for basic traceability, you can leverage this selection without actually touching Manual Scripts. ## Automate and Manual: Implementation Summary The table below summarizes the broad use cases and their implementation in Manual or Automate Scripts. | | | | | --- | --- | --- | | **Use Case** | **What to do - Manual** | **What to do - Automate** | | I have a step that always happens and doesn’t include dynamic data | Hardcode text into the relevant columns; do not use *<>* syntax or conditions | Hardcode text into the lines, do not use *<>* syntax or *{[]}* conditions | | I have a step that always happens, but does include dynamic data (that I added to the model) | Hardcode the supporting text + use *<>* syntax to include Parameters in any of the columns; do not use conditions | Hardcode the supporting text + use *<>* syntax to include Parameters; do not use *{[]}* conditions | | I have steps that sometimes happen (it may or may not include dynamic data) | 1. Apply the condition at the step level (the step content may or may not use <> syntax to include Parameters). 2. Clone the step and change the Conditions to explicitly cover all unique possibilities. | Apply the *{[]}* condition - can be inside the step, inside the Scenario/Outline name, or inside Background. This will handle tests where the steps do happen, based on that condition.
Important: create more Scenario/Outline blocks to cover the tests where the steps don’t happen (i.e., you can’t have both possibilities in the same Scenario/Outline block). | | I have a step that always happens, but its Expected Result is different based on dynamic data (and I didn’t add Expected Result to the model) | 1. Apply the condition at the step level (the step content may or may not use *<>* syntax to include Parameters). 2. Clone the step and change the Conditions to explicitly cover all unique possibilities.
See also Nuances, bullet #2. | N/A | | I have a step that sometimes happens, and its Expected Result is different based on dynamic data (and I didn’t add Expected Result to the model) | 1. Apply the condition at the step level (the step content may or may not use *<>* syntax to include Parameters). 2. Clone the step and change the Conditions to explicitly cover all unique possibilities.
See also Nuances, bullet #2. | N/A | ### Nuances - To include one-off Tests or a small set of negative Testing scenarios or anything like that, you can intentionally **avoid any parameterized syntax in the Scripts block (Manual or Automate → Scenario) and hardcode everything**. That script will be disconnected from the model but will exist in a consolidated space with other scripts and will be exported. - Keep in mind that, since [Constraints](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565551) support dependencies across any number of variables, you could add expected results to the Parameters screen, apply Constraints, then just pass the parameter name in the script without leveraging Conditional Logic described above. Depends on the specific rules involved and your comfort with Constraints. - Make sure you understand the similarities and differences between Conditional steps with Expected Results in the Manual Scripts and Expected Outcomes in the Forced Interactions. There is a significant, yet subtle, difference: - Conditional steps with Expected Results in the Manual Scripts treat the Scenarios data table as a “read-only precondition” - if the combination in the Condition never happens for a scenario, the step will never be generated in export (will always be red in the preview). - Expected Outcomes in Forced Interactions are guaranteed to happen because their conditions (forced values) “edit” the Scenarios table. > ℹ️ For instance, if you need to define an Expected Result that requires three or more specific values to appear in a single step (and you have generated a pairwise set of Scenarios), use the Forced Interactions feature (or a higher combination strength) to ensure the scenario is included in your suite. Then, use the Manual Scripts feature to document the Expected Result for export. > ℹ️ > ℹ️ If your Expected Result requires two or fewer specific values to appear in a single step (and you have generated a pairwise set of Scenarios), use the Manual Scripts Condition feature without additional prep work. - There are situations where certain Testing ideas did not make it into your Test model. Often, these ideas represent expected outcomes or validation steps and may be necessary to complete the Test script. By using the ** syntax in the Scenario Outline block, but intentionally not using the name of a parameter in the test model, you can include *,* and Automate will add an empty column to the Gherkin Examples data table. - Although all generated rows on the Scenarios screen are unique, it's possible to include significantly fewer parameters in a Scenario or Scenario Outline block than are present in the model, and for this subset of Parameters to result in duplicate selections from the data table rows. One use case is in integration Testing, where all Parameters are used in system A to create, e.g., a mortgage application, but then the validation in system B only needs a subset. You want your scripts to be modular enough, so you create one Scenario block for system A and another block for system B. If you just include those selected Parameters in an Automate script for system B, all duplicate combinations will be removed, and the export counts will mismatch. To force every scenario to be included in the Scenario or Scenario Outline export, you can add the *@enumerate_all* Gherkin tag on the line above the words Scenario or Scenario Outline.
Support/Troubleshooting If you have questions or technical issues, please [contact the Support team via the Customer Portal (Jira service management)](https://jira.getxray.app/servicedesk/customer/portal/2/user/login?destination=portal%2F2%2Fcreate%2F28) or [send us a message using the in-app chat](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44577312).