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

In this blog post, we’ll walk you through converting manual test cases into automation scripts. This guide can be applied to any automation tool and aims to clarify the thought process that goes into creating automation test cases. I believe you will find it useful.

Creating an Automation Test Case/Script

Automation testing typically comes after manual testing. Normally, rounds of manual testing have already been conducted on the application under test (AUT). So, most likely, manual test cases already exist and have been run at least once.

For example, consider this manual test case that illustrates how to log into the Gmail.com site. It may seem easy at first glance, but how do we turn it into an automation script? (click on the image to enlarge)

Process to Convert a Manual Test Case into an Automation Script

Below are the guidelines for converting a manual test case into an automation script:

#1) AUT State: The precondition column indicates the specific background state needed to execute a certain step. This is important in two scenarios:

• Test initialization: In this scenario, the browser should be launched and ready to use (we’ll address the availability of the username and password subsequently). How can we achieve this in automation? For instance, in QTP, we can programmatically launch the browser or leverage the ‘record and run settings’ dialogue to set properties. Properly configuring these properties is crucial as they might be the cause why your code works on one system but not on others.

• Step execution: To execute step 2, step 1 needs to be completed. When doing manual testing, we just wait until the execution of the step is finished and the page gets fully loaded. In the automation script, use synchronization or wait statements to ensure the desired state is achieved before continuing.

Note: When running the same code for multiple sets of data, make sure to get the AUT back to the required state before starting each iteration.

#2) Test Steps

We can divide manual test steps into three categories:

• Data entry: These steps require inputting information into the AUT.
• Changing the state of the AUT: These steps bring about changes in the AUT, like navigating to a different page, making certain fields visible, or enabling an edit box.
• Combination: These steps combine data entry and changes in the AUT state. Suppose a checkbox activates a specific field when selected. In this case, inserting the value “True” for the checkbox field brings about a change in the state of the AUT.

The manual test case provided contains only type 1 and type 2 steps.

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

Before crafting an automation script using any tool, spend some time getting to know both the tool and the AUT. Understand how they interact with each other. For instance,, QTP has three recording modes, each functioning differently. Knowing how it recognizes objects can help you select the suitable recording mode for optimal results. If QTP can easily recognize objects in your web app, you can use the standard mode. If not, you might need to use the analog or low-level methods.

Steps for Automation:

• Data entry steps: These steps are the same in both automation and manual methods. The only difference is how you refer to the fields of the AUT. Since a machine performs these steps, make sure to refer to the fields in a way that the tool comprehends. Use the logical names used in the code.
• For AUT change/combination steps: In a manual situation, you execute the action (clicking, checking, inputting) and validate the change all at once. But in an automation scenario, you need separate steps for the action and the verification/validation.
• Comments: Include comments for ease of reading.
• Debugging statements: These are crucial when developing and testing the test itself. Frequently use message boxes to display various values at different stages in test execution. This provides visibility into the test.
• Output statements: Use these to record results or store information in external files such as notepads or Excel sheets.

#3) Verification and Validation

Verification and validation are fundamental to meaningful testing. Typically, you’ll have to use a checkpoint (not necessarily the built-in ones). This necessitates the use of conditional and loop statements to construct the logic.

When choosing an attribute for verification and validation, make sure it’s unambiguous. For example, when verifying a successful login, check if the inbox page is displayed rather than the number of new emails, because the latter is not a constant value.

#4) Test Data

Consider these questions when addressing test data requirements:

• Where should the test data be stored?
• Should the test data be hardcoded or not?
• Are there security risks associated with the test data?
• Can the test data be reused?

In the provided manual test script, having the test data (username and password) prepared in advance is a requirement before starting the test.

#5) Outcomes

In the case of manual testing, you can document the result of each step in the “Actual Result” column. In an automation tool, the output file contains the results of every step executed.

Contemporary automation tools provide robust reporting capabilities. Still, you may need to tailor the test results to meet your needs. Add steps to record results to the result file during test execution for better visibility.

If your chosen tool cannot write to its created result file, it might be a good idea to link an Excel spreadsheet or notepad to each test to record comments about the execution status.

#6) After Operations

After testing is done, there’s no need to mention explicitly the closure of the browser or the AUT in a manual test case. As a tester, this would come to you naturally. But in an automation test case, include these steps in your script as part of the cleanup tasks. Cleanup covers activities like closing connections, applications, and freeing up memory.

By following these guidelines, we can convert our manual test case into a QTP test script using VB Scripting. Here’s what the output looks like: (click on the image to enlarge)

Explanation of Each Step

Step 1: Precondition. We launch Internet Explorer with the URL of Gmail.com via a programmatic method.

Steps 2 & 7: Sync statements. As we discussed earlier, these are key to ensuring the desired state of the AUT is achieved before proceeding to the next step.

Steps 3 & 4: Data input. All data is hardcoded into the script. This is generally not recommended, but it serves as a starting point for our purposes.

Step 5: This step changes the AUT state. Step 5 involves clicking on the Sign in button. There’s no need for further verification when this statement is executed since there’s a subsequent statement. If that subsequent statement can run, it indicates that the previous one was successful. However, if desired, a verification step can be included.

Steps 6 & 8: Comments

Steps 9 & 11: Conditional statement. Verification/Checkpoint. We check if the login was 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 (which can vary), the presence of the permanent inbox link signifies success.

Step 10: Message box. Enhances visibility.

Steps 12 & 13: Cleanup activities. We log out of the account and close the browser.

Wrapping-Up

Transitioning a manual test case into an automation script becomes a straightforward task when you have a well-drafted manual script and adhere to some basic guidelines. While this article didn’t cover frameworks, I focused on the essential building block of a test script. With a solid foundation, it’s easy to refine and enhance your script.

Do you take other factors into consideration, or employ different methods, or find any of the guidelines difficult to adhere to? Please share your feedback in the comments section.

This blog post was penned by Swati Seela, a member of the STH team. Swati has more than 9 years of experience in manual and automation testing and has worked with several multinational corporations. She’s also an instructor of the Software Testing QA Training course. If you are interested in the course, check out the upcoming course schedule here.

PREV Tutorial | NEXT Tutorial