How to Translate Manual Test Cases into Automation Scripts? – A Step by Step Guide with Example

This article provides a step-by-step approach to translating manual test cases into automation scripts. It is a general guide applicable to any automation tool. The goal is to explain the thought process behind creating automation test cases. I hope you find this information helpful.

Designing an Automation Test Case or Script

Automation testing always follows manual testing. Typically, manual testing rounds are already performed on the application under test (AUT). This means that manual test cases already exist and have been executed at least once.

For instance, let’s consider the following manual test case that demonstrates logging in to the Gmail.com site. At first glance, it may seem simple, but how do we convert it into an automation script? (click on the image to enlarge)

Steps to Translate a Manual Test Case into an Automation Script

The following guidelines are to be followed in order to translate the manual test case into an automation script:

#1) State of the AUT: The precondition column signifies the specific background state required for a particular step to be executed. This is important in two scenarios:

• Test initialization: In this case, the browser needs to be available and launched (username and password availability will be addressed shortly). How do we achieve the same in the automation world? Take QTP as an example. You can launch the browser using programmatic statements or utilize the ‘record and run settings’ dialogue to set the properties. Correctly setting these properties is crucial, as they are often the reason why code works on one machine but not on others.

• Step execution: To execute step 2, step 1 needs to be completed. Manually, we can simply wait until the step execution is complete and the page is fully loaded. In your automation script, use sync or wait statements to ensure the desired state is reached before proceeding.

Note: When running the same code for multiple data sets, make sure the AUT is reset to the required state before each iteration starts.

#2) Test Steps

Manual test steps can be categorized into three types:

• Data entry: These steps involve entering information as input into the AUT.
• Change of AUT state steps: These steps induce changes in the AUT. For example, transitioning to a different page, making a certain field visible, or enabling an edit box.
• Combination: These steps involve a combination of data entry and AUT state changes. Consider a checkbox that, when selected, activates a certain field. In this case, entering the value “True” for the checkbox field results in a change of AUT state.

In the provided test case, only type 1 and type 2 steps exist.

• Type 1: Steps 2 & 3
• Type 2: Steps 1 & 4

Prior to creating an automation script using any tool, take the time to analyze both the tool and the AUT. Understand how they interact with each other. For example, QTP has three recording modes and each works differently. Understanding how it identifies objects will help you choose the appropriate recording mode for better results. If QTP can easily identify objects in your web application, you can use the normal mode. Otherwise, you may need to use the analog or low-level methods.

Automation Steps:

• Data entry steps: These steps are similar in automation and manual methods. The only difference is how you refer to the AUT fields. Since the steps are performed by a machine, make sure to reference the fields in a way that the tool understands. Use the logical names used in the code.
• For change of AUT / combination steps: In a manual scenario, you perform the action (clicking, checking, entering) and verify the change in one go. However, in an automation scenario, you need separate steps for the action and the validation/verification.
• Comments: Add comments for readability.
• Debugging statements: These are especially important when creating and testing the test itself. Use message boxes frequently to display various values at different stages of test execution. This provides visibility into the test.
• Output statements: Use these to write results or save information to external files like notepads or Excel sheets.

#3) Verification and Validation

Verification and validation are crucial for meaningful testing. You will typically need to use a checkpoint (not necessarily the built-in ones). This requires the use of conditional and loop statements to build the logic.

When selecting an attribute for verification and validation, ensure that it is unambiguous. For example, when validating a successful login, look for the display of the inbox page rather than the number of new emails, as the latter is not a constant value.

#4) Test Data

Consider the following questions when addressing test data requirements:

• Where should the test data be stored?
• Should the test data be hardcoded or not?
• Are there any security concerns related to the test data?
• Can the test data be reused?

In the given manual test script, having the test data (username and password) readily available is a precondition for starting the test.

#5) Results

In a manual test case, you can record the result of each step in the “Actual Result” column. In an automation tool, the result file contains the results of each step executed.

Modern automation tools offer robust reporting features. However, you may still need to customize the test results to suit your needs. Include steps to write results to the result file during test execution for better visibility.

If your chosen tool does not support writing to its generated result file, it is a good idea to associate an Excel sheet or notepad with each test to record comments about the execution status.

#6) Post Operations

Once testing is complete, there is no need to explicitly mention closing the browser or the AUT in a manual test case. As a tester, you would naturally do it. However, in an automation test case, include these steps in your script as part of the cleanup activities. Clean up includes closing connections, applications, and releasing memory.

Using these guidelines, we can translate our manual test case into a QTP test script that utilizes VB Scripting. The following is the result: (click on the image to enlarge)

Walk Through Each Step

Step 1: Precondition. We programmatically launch Internet Explorer with the Gmail.com URL.

Steps 2 & 7: Sync statements. As discussed earlier, these are crucial for ensuring the AUT reaches the desired state before proceeding to the next step.

Steps 3 & 4: Data entry. All data is hardcoded into the script, which is not advisable but serves as a starting point.

Step 5: Change of AUT step. Step 5 involves clicking the Sign In button. No further verification is needed when this statement is executed since there is a subsequent statement. If the subsequent statement can run, it means the previous one was successful. However, including a verification step is possible if desired.

Steps 6 & 8: Comments

Steps 9 & 11: Conditional statement. Verification/Checkpoint. We check if the login is successful by looking for the presence of an inbox link on the resulting page. Pay attention to the search criteria, which is a link with inner text “inbox.*”. Regardless of the number of new emails received (variable), the presence of the constant inbox link indicates a successful result.

Step 10: Message box. Provides visibility.

Steps 12 & 13: Cleanup activities. Signing out from the account and closing the browser.

Conclusion

Converting a manual test case into an automation script becomes straightforward when you have a well-written manual script and follow basic guidelines. As this article does not cover frameworks, I focused on the fundamental building block of a test script. With a strong foundation, it becomes easy to improve and enhance your script.

Do you consider any other factors, use alternative methods, or find any guidelines challenging to follow? Please share your feedback in the comments section.

This post is written by Swati Seela, a member of the STH team. She holds over 9 years of experience in manual and automation testing, having worked with various multinational companies. Swati is also an instructor for the Software Testing QA Training course. Check out the upcoming batch schedule here if you’re interested in the course.

PREV Tutorial | NEXT Tutorial