What is an autotest design and how does it differ from a manual test design?
Before proceeding to programming, we need to determine which functions we are going to test and how we’ll be checking the results. We need to create a test case.
In general, the basic structure of an autotest looks something like this:
The following example will help you understand the differences between test cases for autotests and manual tests.
Let’s use a simple form from our site as an example -> https://softwarecats.dev.
After clicking the “Discuss a project” button, user will be asked to fill in and submit a simple text form, so that we could contact them and start working together.
Before proceeding to programming, we need to determine which functions we are going to test and how we’ll be checking the results. We need to create a test case.
In general, the basic structure of an autotest looks something like this:
- Prepare the environment.
- Search for the required elements on the page.
- Perform necessary actions with the elements.
- Check the result.
- Free up the resources.
The following example will help you understand the differences between test cases for autotests and manual tests.
Let’s use a simple form from our site as an example -> https://softwarecats.dev.
After clicking the “Discuss a project” button, user will be asked to fill in and submit a simple text form, so that we could contact them and start working together.
Submitting the form is a very important function of our site and it has to be operational round the clock because that’s one of the ways we use to find our clients. That’s why it’s necessary to cover it with autotests.
A test case for manual testing would look like this:
Starting conditions:
The “Discuss a project” form is opened.
The “Submit request” button is displayed.
Steps:
Expected results:
The notification is shown that the request has been successfully sent.
And just to be sure, we also need to check the following:
But since we’re testing just the UI part, let's consider that seeing the notification is enough and guarantees that the message has actually been sent (and received). That’s also why we’ll ignore postconditions like releasing resources—ideally, we would need to remove the test data, which we entered into the form, from the database.
Why can’t we just make an autotest using this exact test case?
If we take a closer look at this case, we’ll see that using it for an autotest would rise a number of questions: in what order should the program fill in the fields, in what order should it interact with elements of the form, what data should be entered into the fields, how can it check the expected result, etc. From the program’s point of view, we don't have enough data.
Let’s rewrite this test as if we’re “explaining” the program what it has to do.
Starting conditions:
Test steps:
Expected results (check if it worked):
A pop-up message is shown: “Thank you! Your request has been successfully submitted.”
All that’s left is to correctly write the test steps in Java and check the expected results.
A test case for manual testing would look like this:
Starting conditions:
The “Discuss a project” form is opened.
The “Submit request” button is displayed.
Steps:
- Fill in the form.
- Click the “Submit request” button.
Expected results:
The notification is shown that the request has been successfully sent.
And just to be sure, we also need to check the following:
- we received the "200 OK" response from the server;
- all data from the form is recorded into the corresponding tables of our database;
- the administrator received an email with all the data from the form.
But since we’re testing just the UI part, let's consider that seeing the notification is enough and guarantees that the message has actually been sent (and received). That’s also why we’ll ignore postconditions like releasing resources—ideally, we would need to remove the test data, which we entered into the form, from the database.
Why can’t we just make an autotest using this exact test case?
If we take a closer look at this case, we’ll see that using it for an autotest would rise a number of questions: in what order should the program fill in the fields, in what order should it interact with elements of the form, what data should be entered into the fields, how can it check the expected result, etc. From the program’s point of view, we don't have enough data.
Let’s rewrite this test as if we’re “explaining” the program what it has to do.
Starting conditions:
- Open the https://softwarecats.dev site in the Chrome browser (you can choose any other browser if it’s important for your test).
- Locate the “Discuss a project” button on the page.
- Click the “Discuss a project” button.
Test steps:
- Locate the “What is your name?” field.
- Set the cursor inside the “What is your name?” field.
- Enter a value into the “What is your name?” field. No character limit, only Latin an Cyrillic characters, lower and upper case.
- Locate the “How can we contact you?” field.
- Set the cursor inside the “How can we contact you?” field.
- Enter a value into the “How can we contact you?” field. No character limit, Latin an Cyrillic characters, lower and upper case, digits, and special characters.
- Locate the “What would you like to discuss?” field.
- Set the cursor inside the “What would you like to discuss?” field.
- Enter a value into the “What would you like to discuss?” field. No character limit for the field, any characters can be used.
- Locate the “Submit request” button on the page.
- Click the “Submit request” button.
Expected results (check if it worked):
A pop-up message is shown: “Thank you! Your request has been successfully submitted.”
All that’s left is to correctly write the test steps in Java and check the expected results.