ATF

ServiceNow Automated Test Framework (ATF) Crash Course - Detailed Notes

I. Introduction to ATF

• What is ATF?
  • Automated Test Framework is an application within ServiceNow.
  • It's designed to automate testing of applications, customizations, and configurations.
• What can you achieve with ATF?
  • Test-Driven Development: Test applications during development.
  • Regression Testing: Test existing business logic.
  • Regular Checkups: Routine ServiceNow checks.
  • Miscellaneous Testing: Any testing use case.
• Where to access ATF:
  • Application Navigator > Automated Test Framework
• What can you test with ATF?
  • Forms (Incident, Change, etc.)
  • Service Catalog Forms (Access Request, etc.)
  • Application Navigator (My Tasks, Open Incidents, etc.)
  • Lists (Incident List, Change List, etc.)
  • Related Lists
  • REST Integrations (Table API)
  • Reports, Dashboards, Emails, and more.

II. Understanding Tests in ATF

• Definition of a Test:
  • An ordered sequence of automated steps.
  • Each step has actions to perform.
  • ATF executes steps and reports the status (pass/fail) of each step and the overall test.
• Where to find existing tests:
  • Application Navigator > Automated Test Framework > Tests
  • These are "out-of-the-box" tests.

III. Creating and Running Your First Test (User Form Validation)

• Scenario: Validate the User form (first name, last name, email).
• Manual Validation (Before Automation):
  • Impersonate a user (e.g., ATF user).
  • Navigate to the User module.
  • Open a user record (e.g., Abel Tuter).
  • Verify the presence of the desired fields.
• Creating the ATF Test:
  1. End Impersonation (Return to the admin account).
  2. Create a New Test:
     • Application Navigator > Automated Test Framework > Tests > New.
     • Name the test (e.g., Validate User Form).
     • Save the test.
  3. Add Test Steps (Replicating Manual Steps):
     • Step 1: Impersonate: Action: Impersonate. Input: Select the user (ATF user).
     • Step 2: Navigate to Module: Action: Navigate to Module. Input: Search for Users, Select the relevant module
     • Step 3: Open Record in List: Action: Open Record in a List. Input: Select the list and the user to open (e.g., Abel Tuter)
     • Step 4: Field State Validation: Action: Field State Validation. Input: Select fields (Email, First Name, Last Name) and choose Visible (or Not visible, Read Only, etc.).
     • Submit: Save the test steps.
• Enabling Test Execution:
  • By default, tests and test suites are disabled on new instances to prevent accidental execution.
  • Go to Automated Test Framework > Properties. (or click the link in the test view Enable test and test suite execution)
  • Set "Enable test and test suite execution" to Yes.
  • Save.
  • Important: Do not enable ATF execution in production environments. Only use it in lower environments (dev, test, UAT).
• Running the Test:
  • Open the test (e.g., Validate User Form).
  • Click "Run Test."
  • Choose a browser.
  • The Client Test Runner will open in a new tab. This is where the test executes.
  • Observe the test steps being executed.
  • The test results will show in the main tab, indicating pass/fail. If it passes, all steps are green.

IV. Client Test Runner Explained

• What is the Client Test Runner?
  • The runtime environment for client-side tests.
  • Executes steps as a specific user within a browser.
  • Supports browsers like Chrome, Edge, and Safari.
• Important Considerations:
  • Tests run faster when the Client Test Runner is in the main open window/tab.
  • If you switch tabs or move to another application while a test is running, it will slow down.
• Headless Browser (Advanced): ServiceNow offers a headless browser feature (runs in the background), reducing the need to have the browser open. Requires configuration. Refer to ServiceNow documentation.
• Managing Client Test Runners:
  • Automated Test Framework > Client Test Runners.
  • Shows the status of runners (online/offline, browser, user, OS, etc.).
• Server-Side vs. Client-Side Steps:
  • Server-side steps do not use the Client Test Runner. They run in the background.
  • You can monitor the status of both types of steps in the popup when you run the test.

V. Demo App and Custom Application Testing

• Demo App Overview: A custom application with two tables: Demo App Request and Demo App Task. This is used to demonstrate testing of custom applications.
  • Demo App Request form: Short Description, Description (mandatory fields), Priority, State, Parent, Assigned to, Configuration Item, and Work notes.
  • Demo App Task is a related list of the Request.
  • Custom UI components (e.g., a Priority pop-up).
• Custom UI Testing: The course highlights the importance of testing custom UI elements.

VI. Detailed Test Creation and Step Configurations

• Rollback of Test Records:
  • ATF automatically rolls back records created or updated during a test execution. This helps keep your data clean.
  • Exception Tables: History tables, ECC Queue table, Email table, Email Log table, Report Execution table, Report Stats, and tables that extend those. Records in these tables are not rolled back.
  • Cannot disable rollback: Disabling rollback is not recommended and can cause platform issues.
• Test Results and Logs:
  • Accessing Test Results:
    • After a test runs, click "Go to Results."
    • From the test record, click the "Test Results" related list.
    • From the Test Results module.
  • Test Result Information:
    • Screenshots (if enabled).
    • Test Output (browser used, user, etc.)
    • Step results (pass/fail status for each step).
    • Test Log (backend logging information).
    • Test Transactions (client-side browser interactions).
  • Screenshot Configuration:
    • Automated Test Framework > Administration > Properties.
    • Enable for all steps (default - takes screenshots for all steps).
    • Enable for failed steps (screenshots only for failing steps - recommended for faster execution).
    • Disable for all steps (no screenshots - fastest execution).
    • Disable for all steps
• Debugging Tests:
  • Automated Test Framework > Administration > Properties > Test Debugging.
  • Enable the Enable test debugging property.
  • Adds a "Debugging" tab in the Client Test Runner, and save the UI test results JSON to the test result.
• Test Step Variables:
  • Input Variables: Provide input values to a test step.
  • Output Variables: Receive data from a test step that can be used as input in subsequent test steps. (Important for chaining steps together).
• Example: Using Input and Output Variables
  • Use a Set Field Values step after an Impersonate step.
  • In Set Field Values, set the Assigned to field.
  • For the Assigned to field, use the output of the Impersonate step. Select the output variable "User Reference".

VII. ATF Test Categories (Hands-On Examples)

• Application Navigator Testing:
  • Scenario: Verify access and module visibility.
  • Steps:
    1. Impersonate.
    2. Verify Application Menu Visibility: Action: Menu Visibility > Input: Demo App.
    3. Verify Module Visibility: Action: Module Visibility > Input: All (from the Demo App application menu). Select the correct application menu.
    4. Navigate to Module: Action: Navigate to Module > Input: Create New (from Demo App).
• Form Testing:
  • Scenario: Verify field visibility, values, and UI actions.
  • Steps:
    1. Impersonate.
    2. Open New Form: Action: Open New Form > Input: Demo App Request table.
    3. Field State Validation: Action: Field State Validation > Input: Select fields and their properties (Visible, Not visible, Read only, Mandatory).
    4. Field Value Validation: Action: Field Value Validation > Input: Field (Priority) and expected value (4 - Low).
    5. Set Field Values: Action: Set Field Values > Input: Fields (Description, Short Description, Assigned to, Configuration Item) and their values.
    6. Custom UI Testing (Assert Text on Page):
       • Find the text in the UI that you want to validate (e.g., from the priority pop-up).
       • Assert Text on Page: Action: Custom UI -> Assert Text on Page.
         • Input: The exact text from the pop-up.
    7. Custom UI Testing (Click Component):
       • Retrieve Page Components: ATF will run the test, navigate to the UI, and list available components (e.g., buttons).
       • Click Component: Action: Custom UI -> Click Component.
         • Input: Select the button from the retrieved list (e.g., "OK").
    8. UI Action - Update Record: Action: Click UI Action
       • Important: This will depend on the UI Action label. This will save
    9. Open Existing Record: Action: Open Existing Record. Input: Select the record you created. Use the output of the form submit step
• List and Related List Testing:
  • Scenario: Verify list records and related list visibility.
  • Steps:
    1. Impersonate.
    2. Navigate to Module: Action: Navigate to Module > Input: All (from Demo App).
    3. Validate Record Present in List: Action: List -> Validate Record Present in a List > Input: Select the record ID.
    4. Open Record in List: Action: Open Record in a List > Input: Select the record.
    5. Set Field Values: Action: Form -> Set Field Values (Set the State field to 'Closed Skipped').
    6. Validate Related List Visibility: Action: Related List -> Validate Related List Visibility -> Input: Related List and visibility setting (not visible after changing state).
• Service Catalog Testing:
  • Scenario: Testing both record producer and catalog items.
  • Record Producer Testing:
    1. Open Catalog Item: Action: Service Catalog -> Open Catalog Item. Select the record producer.
    2. Set Variable Values: Action: Set Variable Values. Input: Populate the needed variables.
    3. Submit the Record Producer: Action: Service Catalog -> Submit Record Producer.
  • Catalog Item Testing:
    1. Open Catalog Item: Action: Service Catalog -> Open Catalog Item. Select the catalog item.
    2. Set Variable Values: Action: Set Variable Values. Input: Set variables (Requester, CI, etc.)
    3. Order Catalog Item: Action: Service Catalog -> Order Catalog Item.
    4. Query Catalog Task. Action: Server -> Record Query. Table is SC Task. Query for tasks with the request number.
    5. Open the catalog task: Action Form -> Open Existing Record. Open the catalog task and use the results of the record query.
    6. Set the State, then Save and Update the Record: Action Form -> Set Field Values. Then Click UI Action. Use the Update UI action
    7. Query related records: Action Server -> Record Query. Query for a Demo App Request where Parent is the catalog task. *If you are getting issues with "Save" replace it with Click UI Action for Update
• Email Testing:
  • Scenario: Verify emails are sent.
  • Steps:
    1. Server -> Record Insert. Input: Create a Demo App Request record. Set the Assigned to field.
    2. Validate Outbound Email. Action: Email -> Validate Outbound Email > Input: Subject Line and other attributes
       • Verify the subject line starts with the expected text.
• Integration (API) Testing:
  • Scenario: Testing REST API calls.
  • Steps:
    1. REST -> Send REST Request (Inbound). Input:
       • Set the authentication profile for REST calls
       • Set the REST method to POST
       • Build the request body using the API Explorer.
       • Headers: content-type, accept and other parameters
       • Path: /api/now/table/demo_app_request
    2. Assert Status Code: Verify the response code (e.g., 201).
    • Note: Outbound REST API testing requires custom test steps.

VIII. Test Templates (Efficiency)

• What are Test Templates?
  • Reusable sets of test steps.
  • Combine commonly used steps.
  • Increase reusability.
• Creating a Test Template:
  1. Automated Test Framework > Administration > Test Templates > New.
  2. Name the template.
  3. Add the desired test steps (e.g., Impersonate, Open New Form, Submit Form).
• Using a Test Template:
  1. Create a new test.
  2. Click "Add Test Template".
  3. Select the desired template.
  4. The template's steps are added to your test.
  5. The table is automatically filled.

IX. Test Suites (Organization)

• What are Test Suites?
  • Hierarchical groupings of related tests (or other test suites).
  • Run as a single job.
• Creating a Test Suite:
  1. Automated Test Framework > Suites > New.
  2. Name the test suite (e.g., Demo App Test Suite).
  3. Add tests to the suite.
  4. Set the execution order.
  5. Abort on failure (default is false - continue running other tests in the suite even if one fails).
• Running a Test Suite:
  • Open the test suite.
  • Click "Run Test Suite."
  • View the results (Test Suite Result shows a summary, including which tests failed).

X. Parameterized Tests (Dynamic Data)

• What are Parameterized Tests?
  • Run the same test multiple times with different data.
  • Eliminates duplicating steps.
  • Increases reusability.
  • Produces separate results for each data set.
• Creating a Parameterized Test:
  1. Create a new test.
  2. Check the "Enable Parameterized Testing" checkbox.
  3. Add parameter definitions (e.g. User using the User table, User,). Specify the type (e.g., Reference) and table (e.g., User).
  4. Create test run data sets:
     • Click on Run Data Sets related list > New.
     • Specify the values for each parameter (e.g., ITIL user, ATF user).
  5. Add test steps.
  6. Use parameters in the test steps. When selecting values, choose "parameter"
     • Example - In the Impersonate step, select the parameter you defined (e.g., User).
• Viewing Results:
  • Parameterized Test Results shows a result for each data set (ITIL user, ATF user, etc.).

XI. Scheduling Test Suites

• Scheduling Test Suites:
  • Schedule test suites to run at specific times.
  • Notify designated users when a scheduled suite completes.
• Creating a Schedule:
  1. Automated Test Framework > Schedules > New.
  2. Name the schedule.
  3. Set the schedule type (e.g., Daily, Monthly, On Demand).
  4. Select the Test Suite(s) to run.
  5. Specify a browser and operating system (for client-side steps).
  6. Add users to the watch list (to receive email notifications).
  7. Scheduled Client Test Runner:
     • The scheduled Client Test Runner is what runs scheduled tests.
     • Automated Test Framework > Scheduled Client Test Runner.
     • This should remain open so that when the scheduled time comes, it will execute the tests.
• Run the tests: If the suite schedule has been saved, and is running, and you are in that Client Test runner window, then it will run, and it will execute them for you.

This expanded outline should provide a solid foundation for understanding and implementing ATF within your ServiceNow environment. Good luck!