We're here to help

Making advanced edits to test steps: test palette

There are a variety of ways that you can use Provar to create more advanced test steps. You can find the following commands within the Test Palette tab, which is located on the right side of Provar desktop. 

In general, you can drag these test step icons into the test that you have open. After you insert the test step, a parameters section to the right will appear allowing you to enter additional information. The additional information required will vary by test step.

Control > Assert

Asserting a test step is used to verify that the information is provided as expected. For example, if you have configured your system to generate a probability percent based on the opportunity stage selected, you can create a test step that verifies if the intended probability percent is generated correctly.

Control > Break

Exits the enclosing loop (For Each, While) or Switch.

Control > Fail Test

While all test assertions should pass in order for a test module to pass, in some situations you may want to temporarily allow particular tests steps to fail. Using this command, this Test Step fails the test case with a message that you can define.

Control > Finally

A group of test steps that are always executed, even if prior test steps have failed. This can be used to do reporting steps, like updating the test result into a spreadsheet.

Control > For Each (aka For Loops)

For Each (Loops) are used to loop through arrays. In the case of Provar, we mainly use For Loops to loop through data.  So if you have a spreadsheet with 10 records, you can use a For Loop to do some actions based on each row of data.

Control > Group Steps

This Test Step creates a labelled grouping for a number of Test Steps within your test case. It can be used to make test cases more readable.

Control > If (Command)

This Test Step evaluates a boolean condition to determine which sub-steps will be executed. A different set of sub-steps can be defined for either result.

This test step is most useful for when you need to execute certain steps based on the value of a variable which is set dynamically during the test run. The variable is checked against the expected value, which returns either TRUE or FALSE as output.

Control > Set Value

This Test Step sets the value of one or more test variables which can then be used in Test Steps. It’s always beneficial to set values in your tests instead of using static data.

Control > Sleep

The ‘Sleep’ test step suspends test execution for the given number of seconds. This step is good for dealing with finicky load times in your environment or needing to pause your test for some reason before continuing.

Control > Switch

A Switch statement is used to select one of several alternatives based on the value of an integer, a character, or a string variable. This executes from the first case value that matches the specified value onwards, continuing until a break is reached. The default is executed if no match is found or if there is no break after a match.

Control > Wait For

Any embedded test steps are executed until the condition is met or the maximum attempt is reached.

Remarks

The Sleep For parameter specifies how long to wait between attempts.

Control > While

This step executes the contained test steps repeatedly until the specified condition is TRUE or until a break is encountered.

UI Testing > UI Action

The UI Action (or ‘UI Do Action’) API is used to perform an action on a field, e.g. setting a field value or clicking a button. This is one of the most common Test Steps in UI testing. UI Action Test Steps are generally added through the Test Builder. You can learn more about UI Action test steps here. 

UI Testing > UI Assert

This test step checks the values or attributes of a UI field and compares them to the expected values. This is most useful for when fields on a UI need to have their values and/or behavior checked in a functional testing flow. This test step can also be used to check messages on a page, using a Page Assertion, or values in a column, using a Column Assertion. You can learn more about UI Assert test steps online here.

UI Testing > UI Connect

The UI Connect test step applies a ‘Non-Salesforce’ Connection into your test case for UI testing. This test step must be added before using any UI test steps for Non-Salesforce UI testing. For Salesforce UI testing, however, API ‘Salesforce Connect’ needs to be used. You can learn more here.

UI Testing > UI Fill

This test step fills one or more fields on a Salesforce screen with data defined in an Excel sheet. This is most useful when you have a single Object screen in which you need to input data into multiple fields and/or enter multiple records. It saves having to create multiple Test Steps to input every field. You can learn more here.

UI Testing > UI Handle Alert

This test step responds to a UI alert dialog which appears after a UI operation has been performed and needs handling to proceed further. This is useful for handling standard alert, confirmation or error messages appearing on certain Salesforce operations such as deleting records.

This test step can be added when mapping an alert through the Test Builder.

It can also be added via the Test Palette by locating the test step and clicking and dragging it into the test case. You can learn more here.

UI Testing > UI Navigate

This test step performs browser refresh and navigation operations as a Test Step. This is most useful when a background event or task has modified some data and the UI needs to be refreshed to reflect accurate data before performing further UI testing. Locate the UI Navigate test step in the Test Palette and click and drag it into the test case. You can learn more here. 

UI Testing > UI On Screen

This test step is used to navigate to a specific screen for UI testing. Test steps of this kind should have additional sub-steps underneath to perform actions on the page, such as a UI Action or UI Assert.

UI On Screen is generally a parent step for operations such as UI Action and UI Assert. (When testing a table, UI With Row will also be added underneath UI On Screen to locate the element within the table.) You can learn more here. 

UI Testing > UI With Row

This test step is used to locate rows within a table or list. Once the table is located through a With Row, other sub-steps can be added underneath to perform operations on the table fields (e.g. a UI Action or a UI Assert). You can learn more here.

BDD

Provar supports a Behavior-Driven Development (BDD) approach to creating test cases for automation. Provar has a number of BDD test steps as well as a BDD reporting feature. This section includes BDD commands including And, But, Given, Then and When. You can learn more about how to apply these commands online here

Database

This section includes commands that you can use to test external databases. You can learn more about Database Testing Setup and Database Operations online. 

Database > DB Connect

This creates a connection to a relational database.

Database > DB Delete

This deletes an existing row from a database table.

Database > DB Insert

This inserts a new row into a database table and stores created row’s Id.

Database > DB Read

This reads a row from a database and stores its values with optional assertions. This API works best when you drag data from a database browser. You can use the Configure Parameters tool item to choose the columns you want to read/assert.

Database > DB Update

This updates an existing row in a database table.

Database > SQL Query

This reads one or more rows from a database and stores the values with optional assertions.

Design & Reporting

These commands are designed to help you configure reports including the text that is included in the enclosing design step’s actual results.

Design & Reporting > Actual Result

You can use this to specify the text that is included in the enclosing design step’s actual results.

Design & Reporting > Design Step

A high-level group of steps that is reported on in execution reports in order to make your test cases more readable.

Force.com

You can use Provar to test Force.com, a Salesforce Platform as a Service (PaaS) product designed to simplify the development and deployment of cloud-based applications and websites. 

Force.com > Apex Bulk

This command bulk creates, updates or deletes Salesforce records via the Bulk API.

Force.com > Apex Execute

This test step executes an anonymous block against Salesforce (non-UI).

Force.com > Approve Work Item

This one is easy. It approves a work item. 

Force.com > Assert Salesforce Layout

You can use this command to assert a Salesforce layout against expected values in spreadsheet.

Force.com > Convert Lead

This converts a Salesforce Lead into an Account, Contact, or (optionally) an Opportunity (non-UI).

Force.com > Extract Salesforce Layout

This test step extracts layout information for a Salesforce object into a spreadsheet.

Force.com > Log for Cleanup

This test step logs one or more Salesforce IDs for cleanup at the end of the test run. You can use this in instances where Provar cannot automatically work out which objects have been created. This is often the case for VisualForce pages.

Force.com > Salesforce Connect

This step opens and API connection to the Salesforce org, the UI connection and logon only happen when the first UI test step is encountered.

Force.com > Submit for Approval

This submits a Salesforce object for approval. 

List > List Compare

This test step compares values of two lists of an identical structure. It can compare and report on selected columns or all columns. Lists can be compared row by row, if both lists have the same row order, or alternatively the test step can match list rows based on values in defined columns prior to making the comparison. You can learn more online here.

Messaging

In your typical test flow where you need to test emails, you can use Provar to test if emails are sent and received correctly. The following describe how to test these actions in Provar.

Messaging > Publish Message

This sends a message to a multi-recipient destination via your messaging system.

Messaging > Receive Message

This call waits for a message to be received (see the Subscribe API if don’t want to wait). Use the Connections tab in the Test Settings view to set up your destination.

Messaging > Send Message

This test step sends a message to a destination (e.g. a messaging system). You can use the Connections tab in the Test Settings view to set up your destination.

Messaging > Subscribe

This test steps validates if a user starts receiving messages from a message source (typically a newsletter, etc.). This call doesn’t wait for the message to arrive, but adds them so the resulting subscription (see Receive Message if you want to wait). You can use the Connections tab in the Test Settings view to set up your source.

Read/Write > Read

Reads the contents of a file or URL and stores it in a variable.

Read/Write > Write

Even our documentation pushes people for using “Add a parameter source”….this should be removed or changed to have the parameter source fields.

ServiceMax > Dispatch Work Order

Assigns a work order to a technician which creates an Event in their calendar.

ServiceMax > SmaxMobileTools

This test step syncs data captured from a mobile device.

String APIs > Match

This test step applies a reqular expression to a text value and stores the matches.

String APIs > Replace

This test step replaces all instances of a string with another.

String APIs > Split

This test step splits a string on a separator and stores the result.

Web > Web Connect

Authenticates the web service and returns an authorization token.

Web > Web Request (HTTP/REST)

Calls a RESTful web service and returns the response.

Web > Web Servie Request (SOAP)

Submits a SOAP request to a web service and returns the response.