{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":1839,"path":"application-development/automated-test-framework-atf/test-steps-server-category.md","title":"Server category","bundle":null,"doc_type":null,"release":"australia","body":"\n# Server category\n\nPerform server-side operations. For example, query and update a record, impersonate a user, or run a server-side script.\n\n## Create a User\n\nCreate a user with specified roles and groups for the test. The user record gets rolled back after the test completes.\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nExecution order\n\n\n\nInteger specifying the order in which the test executes this step.As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them. You can change this default order by editing the **Execution order** values.\n\n
\n\nApplication\n\n\n\nApplication scope in which the system runs this step.\n\n
\n\nActive\n\n\n\nOption to activate this test step for use.\n\n
\n\nTest\n\n\n\nName of the test that you're adding the step to.\n\n
\n\nStep config\n\n\n\nName of the step.\n\n
\n\nNotes\n\n\n\nNotes about the test step.\n\n
\n\nFirst name\n\n\n\nFirst name of the user.\n\n
\n\nLast name\n\n\n\nLast name of the user.\n\n
\n\nRoles\n\n\n\nAssigned roles of the user.\n\n
\n\nGroups\n\n\n\nAssigned groups of the user.\n\n
\n\nImpersonate this user\n\n\n\nOption to impersonate the new user.\n\n
|Field|Description|\n|-----|-----------|\n|user|The user ID of the user impersonated.|\n\n## Impersonate\n\nImpersonate the specified user for the test.\n\n**Impersonate** specifies a user for executing subsequent steps in this test. It works for both server-side and browser-side steps and stays in effect until changed with another **Impersonate** step or until the test ends. The impersonation automatically ends when the test is over.\n\n**Note:**\n\n- Do not impersonate a user with the test author role. Doing so can lead to conflicts that interfere with executing the test.\n- Tests which involve impersonated users which no longer exist fail.\n\n **Tip:** It is recommended to create a new user to avoid data dependencies. See [Create a User](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/automated-test-framework-atf/test-steps-server-category.md), for more information.\n\n- Do not rely on user IDs being consistent across different instances. The system dynamically assigns users IDs, so the ID for a particular user often differs from one instance to the next.\n- When exporting and importing automated tests, keep in mind that update sets do not update the user field.\n- Tests can impersonate users with the snc\\_external role, which allows testing users who do not have login access. See [Explicit Roles](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-security/explicit-roles.md) for requirements of the snc\\_external role.\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nExecution order\n\n\n\nInteger specifying the order in which the test executes this step.As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the **Execution order** values.\n\n
\n\nActive\n\n\n\nOption to activate this test step for use.\n\n
\n\nApplication\n\n\n\nApplication scope in which the system runs this step.\n\n
\n\nTest\n\n\n\nRead-only name of the test that you're adding the step to.\n\n
\n\nUser\n\n\n\nThe user ID for the test to impersonate.\n\n
|Field|Description|\n|-----|-----------|\n|user|The user ID of the user impersonated.|\n\n## Search for a Catalog Item\n\nSearches for a catalog item or record producer in the specified catalog and category. You can perform this step both in Platform and Service Portal.\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nExecution order\n\n\n\nInteger specifying the order in which the test executes this step.As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the **Execution order** values.\n\n
\n\nActive\n\n\n\nOption to activate this test step for use.\n\n
\n\nApplication\n\n\n\nApplication scope in which the system runs this step.\n\n
\n\nTest\n\n\n\nRead-only name of the test that you're adding the step to.\n\n
\n\nStep config\n\n\n\nRead-only name of the step.\n\n
\n\nDescription\n\n\n\nDescription of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.\n\n
\n\nNotes\n\n\n\nNotes about the test step.\n\n
\n\nSearch in Portal only\n\n\n\nSelected if the search is restricted to the Service Portal only. Otherwise, not selected.\n\n
\n\nSearch term\n\n\n\nTerm used to search for a catalog item.\n\n
\n\nCatalog\n\n\n\nCatalog in which to search for the catalog item.\n\n
\n\nCategory\n\n\n\nCategory in which to search for the catalog item.\n\n
\n\nAssert item\n\n\n\nCatalog items that should be available in the search results.\n\n
\n\nAssert Type\n\n\n\nSpecifies how searching the catalog item affects the test:- **Assert Item present in search result**: Test passes only if the assert item is present in the search result.\n- **Assert Item not present in search result**: Test passes only if the assert item is not present in the search result.\n\n
|Field|Description|\n|-----|-----------|\n|catalog\\_item\\_id|The sys\\_id of the first catalog item found that the user can view.|\n\n## Record Query\n\nQuery the database to verify that a record exists matching the conditions set in this step.\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nExecution order\n\n\n\nInteger specifying the order in which the test executes this step.As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the **Execution order** values.\n\n
\n\nActive\n\n\n\nOption to activate this test step for use.\n\n
\n\nTimeout\n\n\n\nNumber of seconds allowed before the step fails. If the validation fails, the system repeats the step until it reaches the duration of the timeout. If the validation fails after the timeout duration has passed, the step fails.\n\n
\n\nApplication\n\n\n\nApplication scope in which the system runs this step.\n\n
\n\nTest\n\n\n\nRead-only name of the test that you're adding the step to.\n\n
\n\nStep config\n\n\n\nRead-only name of the step.\n\n
\n\nDescription\n\n\n\nDescription of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.\n\n
\n\nEnforce security\n\n\n\nSelected to enforce ACLs. Otherwise, not selected.\n\n
\n\nNotes\n\n\n\nNotes about the test step.**Note:** Use the condition builder to set the field value. The condition builder displays an appropriate control for the field data type. For example, a reference field displays a **Lookup record** control.\n\n
\n\nAssert type\n\n\n\nSpecifies how querying the record affects the test:- **There is at least one record matching the query**: The test fails if there are no records matching the query.\n- **No records match the query**: The test fails if any records match the query.\n\n
\n\nTable\n\n\n\nThe table to be queried.\n\n
\n\nConditions\n\n\n\nConditions used to run the query.\n\n
|Field|Description|\n|-----|-----------|\n|table|The table queried.|\n|first\\_record|The first record resulting from the query.|\n\n**Note:** If you don’t update your record query test step, the original record query test step still functions the same way as before, irrespective of it being termed as **\\(Deprecated\\)**.\n\n## Record Insert\n\nInserts a record into a table with the field values you specify.\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nExecution order\n\n\n\nInteger specifying the order in which the test executes this step.As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the **Execution order** values.\n\n
\n\nActive\n\n\n\nOption to activate this test step for use.\n\n
\n\nApplication\n\n\n\nApplication scope in which the system runs this step.\n\n
\n\nTest\n\n\n\nRead-only name of the test that you're adding the step to.\n\n
\n\nStep config\n\n\n\nRead-only name of the step.\n\n
\n\nDescription\n\n\n\nDescription of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.\n\n
\n\nNotes\n\n\n\nNotes about the test step.**Note:** Use the condition builder to set the field value. The condition builder displays an appropriate control for the field data type. For example, a reference field displays a **Lookup record** control.\n\n
\n\nAssert type\n\n\n\nSpecifies how inserting the record affects the test:- **Record successfully inserted**: Test fails if the record was not successfully inserted.\n- **Record was not inserted**: Test fails if the record was successfully inserted.\n\n
\n\nEnforce security\n\n\n\nSelected to enforce ACLs and the read-only role. Otherwise, not selected.\n\n
\n\nTable\n\n\n\nThe table into which the record should be inserted.\n\n
\n\nConditions\n\n\n\nSpecific field values to be set when the test runs this step.\n\n
|Field|Description|\n|-----|-----------|\n|table|The table to which the new record belongs.|\n|record\\_id|The sys\\_id of the new record.|\n\n## Record Update\n\nChanges field values on a record on the server.\n\n**Note:** To ensure that the changes were applied, follow this step with a **Record Validation** step.\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nExecution order\n\n\n\nInteger specifying the order in which the test executes this step.As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the **Execution order** values.\n\n
\n\nActive\n\n\n\nOption to activate this test step for use.\n\n
\n\nApplication\n\n\n\nApplication scope in which the system runs this step.\n\n
\n\nTest\n\n\n\nRead-only name of the test that you're adding the step to.\n\n
\n\nStep config\n\n\n\nRead-only name of the step.\n\n
\n\nDescription\n\n\n\nDescription of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.\n\n
\n\nNotes\n\n\n\nNotes about the test step.**Note:** Use the condition builder to set the field value. The condition builder displays an appropriate control for the field data type. For example, a reference field displays a **Lookup record** control.\n\n
\n\nAssert type\n\n\n\nSpecifies how updating the record affects the test:- **Record successfully updated**: Test fails if the record was not successfully updated.\n- **Record was not updated**: Test fails if the record was successfully updated.\n\n
\n\nEnforce security\n\n\n\nSelected to enforce ACLs and the read-only role. Otherwise, not selected.\n\n
\n\nTable\n\n\n\nThe table containing the record to be updated.\n\n
\n\nRecord\n\n\n\nID of the record to be updated.\n\n
\n\nField values\n\n\n\nFields for which you want to set values and the values you want to set for those fields.**Note:** Use the condition builder to set the field value. The condition builder displays an appropriate control for the field data type. For example, a reference field displays a **Lookup record** control.\n\n
**Note:** Record Update step succeeds even if a field on the record is blocked by ACL. Use the [Record Validation](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/automated-test-framework-atf/test-steps-server-category.md) step after Record Update to check whether a particular field was modified, or use the [Form steps](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/automated-test-framework-atf/test-steps-form-category.md) to evaluate ACL conditions for individual fields on a record.\n\n## Record Delete\n\nDeletes a specified record in a table.\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nExecution order\n\n\n\nInteger specifying the order in which the test executes this step.As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the **Execution order** values.\n\n
\n\nActive\n\n\n\nOption to activate this test step for use.\n\n
\n\nApplication\n\n\n\nApplication scope in which the system runs this step.\n\n
\n\nTest\n\n\n\nRead-only name of the test that you're adding the step to.\n\n
\n\nStep config\n\n\n\nRead-only name of the step.\n\n
\n\nDescription\n\n\n\nDescription of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.\n\n
\n\nNotes\n\n\n\nNotes about the test step.\n\n
\n\nAssert type\n\n\n\nSpecifies how updating the record affects the test:- **Record successfully deleted**: Test fails if the record was not successfully deleted.\n- **Record was not deleted**: Test fails if the record was successfully deleted.\n\n
\n\nEnforce security\n\n\n\nSelected to enforce ACLs and the read-only role. Otherwise, not selected.\n\n
\n\nTable\n\n\n\nThe table containing the record to be deleted.\n\n
\n\nRecord\n\n\n\nID of the record to be deleted.\n\n
## Record Validation\n\nValidates that a record meets the specified conditions on the server side.\n\nFor the **Record Validation** step, specify the values you want to test using the standard conditions builder. You can apply several conditions to the same field.\n\nThis step passes if the overall condition is satisfied and fails if it is not. If you need to test the values of individual fields independently of each other, include a separate **Record Validation** step for each value to be tested.\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nExecution order\n\n\n\nInteger specifying the order in which the test executes this step.As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the **Execution order** values.\n\n
\n\nActive\n\n\n\nOption to activate this test step for use.\n\n
\n\nTimeout\n\n\n\nNumber of seconds allowed before the step fails. If the validation fails, the system repeats the step until it reaches the duration of the timeout. If the validation fails after the timeout duration has passed, the step fails.\n\n
\n\nApplication\n\n\n\nApplication scope in which the system runs this step.\n\n
\n\nTest\n\n\n\nRead-only name of the test that you're adding the step to.\n\n
\n\nStep config\n\n\n\nRead-only name of the step.\n\n
\n\nDescription\n\n\n\nDescription of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.\n\n
\n\nNotes\n\n\n\nNotes about the test step.**Note:** Use the condition builder to set the field value. The condition builder displays an appropriate control for the field data type. For example, a reference field displays a **Lookup record** control.\n\n
\n\nAssert type\n\n\n\nSpecifies how validating the record affects the test:- **Record successfully validated**: The test fails if the record does not match the conditions.\n- **Record not found**: Test fails if the record is found.\n\n
\n\nTable\n\n\n\nThe table that contains the field to be validated.\n\n
\n\nRecord\n\n\n\nThe record that contains the field to be validated.\n\n
\n\nField values\n\n\n\nSpecific fields to be validated when the test runs this step.\n\n
## Run Server Side Script\n\nExecutes a script on the server.\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nExecution order\n\n\n\nInteger specifying the order in which the test executes this step.As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the **Execution order** values.\n\n
\n\nActive\n\n\n\nOption to activate this test step for use.\n\n
\n\nApplication\n\n\n\nApplication scope in which the system runs this step.\n\n
\n\nTest\n\n\n\nRead-only name of the test that you're adding the step to.\n\n
\n\nStep config\n\n\n\nRead-only name of the step.\n\n
\n\nDescription\n\n\n\nDescription of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.\n\n
\n\nNotes\n\n\n\nNotes about the test step.\n\n
\n\nJasmine version\n\n\n\nThe version of the Jasmine testing framework to use for running the server-side script. Any new scripts you create use Jasmine version 3.1. Your existing scripts can continue to use Jasmine version 1.3, or you can upgrade them to Jasmine version 3.1.\n\n
\n\nTest script\n\n\n\nThe javascript for the server to execute. Supports the Jasmine testing framework.**Note:** steps\\(SYS\\_ID\\) can be defined as a function to retrieve Output variable data from a step that executed earlier in the test.\n\n The Run Server Side Script test step now supports parameters as step inputs.\n\n
|Field|Description|\n|-----|-----------|\n|record\\_id|The sys\\_id output by the server-side script.|\n|table|The table output by the server-side script.|\n\n**Note:** If the script creates data, the system rolls back that data after all steps in the test finish. The output for the Run Server Side Script test step now indicates the line and the line number for the cause of failure.\n\n- Test script\n\n ```\n // Test step 1 - add data\n var now_GR = new GlideRecord('sc_task');\n // this sample step's Step config has Output variables named table and record_id\n outputs.table = 'sc_task';\n outputs.record_id = gr.insert();\n // Test step 2 - access added data and validate\n // check that the record exists (or that business logic changed it)\n var now_GR = new GlideRecord(\"sc_task\");\n gr.get(steps(PREVIOUS_STEP_SYS_ID).record_id);\n assertEqual({name: \"task gr exists\", shouldbe: true, value: gr.isValidRecord()});\n stepResult.setOutputMessage: Log a message to step results after step executes.\n Can only be called once or will overwrite previous message\n ```\n\n- Create a suite of test scripts\n\n ```\n var now_GR = new GlideRecord('sc_task');\n gr.setValue('short_description', 'verify task can be inserted');\n var grSysId = gr.insert();\n var justCreatedGR = new GlideRecord('sc_task');\n if (justCreatedGR.get(grSysId)) {\n stepResult.setOutputMessage(\"Successfully inserted task record\");\n return true; // pass the step\n } else { \n stepResult.setOutputMessage(\"Failed to insert task record\");\n return false; // fail the step\n }\n ```\n\n- Jasmine test\n\n ```\n describe('my suite of script tests', function() {\n it('should meet expectations', function() {\n expect(true).not.toBe(false);\n });\n });\n // make sure to uncomment jasmine.getEnv().execute(); outside the function body\n assertEqual: A function used to compare that assertion.shouldbe == assertion.value;\n in case of failure it throws an Error and logs that the assertion by name has failed\n ```\n\n **Note:** `describe` is only supported in Global scope. Use `describe` to create a suite of test scripts and `it` to define test expectations.\n\n- Logs message to test step output\n\n ```\n var testAssertion = {\n name: \"my test assertion\",\n shouldbe: \"expected value\"\n value: \"actual value\",\n };\n assertEqual(testAssertion); // throws Error, logs message to test step output\n ```\n\n- See [Step Execution Scripts](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/automated-test-framework-atf/atf-config-script.md) for Run Server Side script example.\n\n## Replay Request Item\n\nGet the item and requester from an existing request item, add the item to a new cart for that user, and place an order.\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nExecution order\n\n\n\nInteger specifying the order in which the test executes this step.As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the **Execution order** values.\n\n
\n\nActive\n\n\n\nOption to activate this test step for use.\n\n
\n\nApplication\n\n\n\nApplication scope in which the system runs this step.\n\n
\n\nTest\n\n\n\nRead-only name of the test that you're adding the step to.\n\n
\n\nStep config\n\n\n\nRead-only name of the step.\n\n
\n\nDescription\n\n\n\nDescription of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.\n\n
\n\nNotes\n\n\n\nNotes about the test step.\n\n
\n\nOriginal Request Item\n\n\n\nThe request item to be replayed.\n\n
|Field|Description|\n|-----|-----------|\n|table|The table to which the replayed request item belongs.|\n|request|The replayed request item.|\n\n**Related topics** \n\n\n[Automated Test Framework use case: test a Service Catalog request](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/automated-test-framework-atf/atf-serv-cat-use.md)\n\n## Log\n\nLogs a message and stores it as a step result.\n\nThe log message can contain variables and other information pertaining to the test. The message is stored as a step result.\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nExecution order\n\n\n\nInteger specifying the order in which the test executes this step.As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the **Execution order** values.\n\n
\n\nActive\n\n\n\nOption to activate this test step for use.\n\n
\n\nApplication\n\n\n\nApplication scope in which the system runs this step.\n\n
\n\nTest\n\n\n\nRead-only name of the test that you're adding the step to.\n\n
\n\nStep config\n\n\n\nRead-only name of the step.\n\n
\n\nDescription\n\n\n\nDescription of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.\n\n
\n\nNotes\n\n\n\nNotes about the test step.\n\n
\n\nLog\n\n\n\nThe message to be logged. To include the value of an output variable from a previous step, click the input value icon \\(\\[Omitted image \"rem-value-icon.png\"\\] Alt text: Input value icon\\) and follow the procedure to [Pass values from one automated test step to another](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/automated-test-framework-atf/atf-retrieve-value.md).\n\n
## Add Attachments to Existing Record\n\nAdd one or more mandatory attachments to the specified record. Use **Upload Attachments** to select from the attachments the test step adds to the record.\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nExecution order\n\n\n\nInteger specifying the order in which the test executes this step.As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them. You can change this default order by editing the **Execution order** values.\n\n
\n\nApplication\n\n\n\nApplication scope in which the system runs this step.\n\n
\n\nActive\n\n\n\nOption to activate this test step for use.\n\n
\n\nTest\n\n\n\nName of the test that you're adding the step to.\n\n
\n\nStep config\n\n\n\nName of the step.\n\n
\n\nNotes\n\n\n\nNotes about the test step.\n\n
\n\nTable\n\n\n\nValid table selection from the list.\n\n
\n\nRecord\n\n\n\nPre-existing record either from before the test or inserted as a part of the test.\n\n
\n\nUpload Attachments\n\n\n\nButton to add one or more mandatory attachments to the record.\n\n
## Checkout Shopping Cart\n\nSubmits the cart and generates a request. You can perform this step both in the ServiceNow AI Platform and Service Portal.\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nExecution order\n\n\n\nInteger specifying the order in which the test executes this step.As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the **Execution order** values.\n\n
\n\nActive\n\n\n\nOption to activate this test step for use.\n\n
\n\nTimeout\n\n\n\nNumber of seconds allowed before the step fails. If the validation fails, the system repeats the step until it reaches the duration of the timeout. If the validation fails after the timeout duration has passed, the step fails.\n\n
\n\nApplication\n\n\n\nApplication scope in which the system runs this step.\n\n
\n\nTest\n\n\n\nRead-only name of the test that you're adding the step to.\n\n
\n\nStep config\n\n\n\nRead-only name of the step.\n\n
\n\nDescription\n\n\n\nDescription of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.\n\n
\n\nNotes\n\n\n\nNotes about the test step.\n\n
\n\nAssert Type\n\n\n\nCriteria for the test to pass.- **Empty cart**\n\nTest fails if the cart is not empty.\n\n- **Successfully Checkout cart**\n\nTest fails if the cart is not successfully checked out.\n\n\n
\n\nRequested For\n\n\n\nUser for whom the request is generated.\n\n
\n\nDelivery Address\n\n\n\nDelivery address for the request.\n\n
\n\nSpecial Instructions\n\n\n\nSpecial instructions for the request.\n\n
|Field|Description|\n|-----|-----------|\n|request\\_id|The sys\\_id of the submitted request.|\n\n## Custom Scripted StepConfig\n\nProvides an example of scripts for a custom step configuration.\n\nThis example checks if the user name provided starts with the letter A. This step is useful primarily to users with the \\[atf\\_test\\_admin\\] role. Users with the \\[atf\\_test\\_admin\\] role can view the example scripts by opening the record for this step in [Step configurations](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/automated-test-framework-atf/step-configurations-module.md).\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nExecution order\n\n\n\nInteger specifying the order in which the test executes this step.As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the **Execution order** values.\n\n
\n\nActive\n\n\n\nOption to activate this test step for use.\n\n
\n\nApplication\n\n\n\nApplication scope in which the system runs this step.\n\n
\n\nTest\n\n\n\nRead-only name of the test that you're adding the step to.\n\n
\n\nStep config\n\n\n\nRead-only name of the step.\n\n
\n\nDescription\n\n\n\nDescription of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.\n\n
\n\nNotes\n\n\n\nNotes about the test step.\n\n
\n\nUser\n\n\n\nThe user whose name the system checks to see if it starts with the letter **A**. To include the value of an output variable from a previous step, click the input value icon \\(\\[Omitted image \"rem-value-icon.png\"\\] Alt text: Input value icon\\) and follow the procedure to [Pass values from one automated test step to another](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/automated-test-framework-atf/atf-retrieve-value.md).\n\n
|Field|Description|\n|-----|-----------|\n|value|The name of the user.|\n\n**Related topics** \n\n\n[Create custom step configuration](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/automated-test-framework-atf/atf-create-custom-step.md)\n\n[Step execution scripts](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/automated-test-framework-atf/atf-config-script.md)\n\n[Step description generation script](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/automated-test-framework-atf/atf-config-desc-script.md)\n\n"}}