Any test automation contains a so-called core, which consists of three parts – stimulus, responses, and a certain amount of checks. Next, let’s talk in detail about each component to highlight all important things that can help make your automation even more flexible.

Concepts of Stimulus, Response, and Test

Simply put, a stimulus is a particular action that triggers a specific response. In software testing and automation, incentives can come from a variety of sources, for example:

• Keystroke;
• API call;
• Entering a special command in the operating system.

Any of these actions should elicit a specific response.

Regarding the response, this is the reaction or the result of the introduction of the stimulus. This is what happens as a result of the appearance of the stimulus.

Looking at the examples of incentives above, the responses that would correspond to them might be as follows:

1. Refreshing the page or navigating by pressing a key;
2. A backward message that will be returned by the API call;
3. External software returns the total by entering a command inside a specific OS.

It is worth noting that the same stimulus can elicit a multitude of responses. Moreover, a certain response can be a reaction to several different stimuli at once. This is important to understand since a QA engineer may need to test multiple combinations, responses, or incentives at once.

Tests are what should be used to determine if the correct answer was received in response to a stimulus.

Tests can be in the following form:

1. Can the user go to the correct page after pressing a certain key?
2. Did he/she receive the correct values in the response email after the API call?
3. Could the external program show the correct results in response to a system call?

Usually, all checks programmed in automation are displayed as statements, and not in the form of questions, as described above.

Tests and Determinism

The conventional wisdom of software testing says that all checks must be exclusively deterministic. In other words, they always have to determine whether a statement is correct or not.

Simply put, if you cannot understand whether the statement is effective or not, then you will not be able to say whether your test should inform about the success or failure of the check performed.

If you are unable to fully define success or failure, you will probably lose faith in the automation you are doing and the information it provides. It follows that purely deterministic tests are useful, right? In general, yes, but there are some exceptions.

For the most part, deterministic tests are essential to delivering customer-trustworthy and valuable test results: this practice is extremely effective for classic automated test scripts. But if you go beyond the scope of classical automation in the field of unconventional automation, then non-deterministic tests can also be of great benefit.

With all this, this automation approach is not just proof of a passed or failed test. It is about PCs, which, in one way or another, help testers in their work performing repetitive operations and comparing data.