Test Automation is simply a way to simulate human interaction on the application UI and perform logical validations in an automated fashion. These validations can include checking information on the UI screen or verifying information from files, databases, and API calls. An Automated Test Case is a set of instructions or statements that allow you to interact with the screens and query/verify different system resources.
A statement is an instruction that accomplishes a unit task, such as clicking a button or verifying text on a screen or connecting to a database, etc.
The statement describes what needs to be accomplished and includes input information relevant to the operation. For example, a statement to enter text in an input field requires to provide information on
- which field to enter text and
- what text to enter
Here is an example of a simple automated test procedure, which verifies login functionality on an application (represented in no-code, English format).
Enter “john.schultz” in the User Name field.
Enter “*****” in the Password field.
Click on the Sign In button.
Verify that “Welcome John!" is displayed on the page.
In the above example, the first statement is entering the given email address in the “User Name” field. For this to function, you need to teach the system what the “User Name” field looks like. How to identify “User Name” on the screen when the test is running? The first 3 statements in the above logic refer to one of the fields on the screen.
Teaching the system how to identify an element, also called Element Identification is a core function in a test automation tool. An automation engineer defines the attributes that can uniquely identify an Element on the screen. For example, “User Name” may be defined by its id (as coded by your developer) or by its placeholder text, or by a combination of other attributes. In your automation setup, you will define all the elements which are required as part of your test logic.
Learning how to correctly set up Element ID is an important part of the automation learning curve. And we will investigate this objective with several different examples.
In the above example, apart from identifying the target element, some statements also require information or test data. For example, a statement to enter text in a field needs to be provided with the test data (email address, in the first line of the logic above). Quite often, you do not want to hard-code this data in a statement. It is a common practice to “parameterize” this information. This is done for multiple reasons:
- Allow using your test logic with multiple sets of data, rather than fixed with a literal data
- Read data from external sources such as a database or a file
- Enable passing data between different steps of your test logic etc.
Parameterization is a core concept in automation and test design, and we will deal with it very thoroughly. This approach enables a very important capability called "data-driven testing". You will be able to exercise the same test with multiple input sets of data, which is what makes testing usually cumbersome.
An automation test script is a collection of statements. Writing any realistic automation test will often involve common logical constructs such as performing an activity conditionally or repeating certain activity multiple times etc. There are some special types of statements to accomplish this. As we move along, we will learn about some of these most common logical constructs.
Design and Architecture
Design thinking is essential in managing the real-world complexity and challenges of automation. It is essential to be able to organize and modularize your automation suite in order for it to be easy to maintain. Application-under-test (AUT) is not always static. Application functionality is constantly changing. Automation scripts must be flexible enough to allow for these changes. Automation scripts can become fragile and unmaintainable if they aren't designed early.
We will be emphasizing these best practices and design elements from the get-go. And keep in mind, good design is not necessarily complicated, but more of a discipline at the fundamental level.