Converting 🔄
Manual test cases into Automation

My name is Volodymyr and I work as a Automation QA Tech Lead Engineer. I like sharing my knowledge and experience in testing fields. In particular, I’m a Test Automation instructor at Softserve IT Academy. I teach students Ruby automation. I am really always happy to mentor them in the way of their professional path.

In this article, I try to provide a step-by-step guide on how to identify test cases suitable for automation, assess their automatability, and prioritize them based on their importance and potential for test automation. Also, emphasise on use of Cucumber and such popular approach as BDD (Behavior Driven Development) in the automation community. The article includes a sample feature file that manual QC/QA engineers can use to prepare for future automation.

👉 The most frequent question that I heard as Automation QA Engineer from manual QC is:

– “Is it possible to convert manual test cases into Automation?”

– The short answer is: “Yes!”, but let’s go deep and try to find tools and possible ways to move manual cases into automation.

Why is manual testing decreasing?

Manual testing is an essential part of the software testing process. However, manual testing can be time-consuming, costly, and error-prone. Automation can reduce testing time, increase test coverage, and improve accuracy. Therefore, identifying manual test cases that can be automated can help optimize the testing process.

Which manual test cases can be automated?

The first step in identifying manual test cases that can be automated is to conduct a review and audit of the existing manual test cases. The review and audit process should focus on identifying test cases that meet the following criteria:

  • Repetitive: Test cases that need to be executed multiple times with different data inputs or configurations.
  • Time-consuming: Test cases that require a significant amount of time to execute manually.
  • Prone to human error: Test cases that are prone to errors due to human factors such as fatigue, distraction, or lack of attention to detail.
  • Stable: Test cases that are stable and not subject to frequent changes.

Once the test cases that meet the above criteria are identified, the next step is to assess their automatability. The assessment of test cases should consider the following factors:

  • Test case design: Test cases should be designed in a way that is suitable for automation. This includes factors such as clear and unambiguous steps, input data, and expected results.
  • Test case complexity: Test cases that are too complex may be difficult to automate and maintain.
  • Test environment: The test environment should be suitable for automation, and automation tools should be able to interact with it effectively.
  • Automation tools: The automation tools should be capable of automating the identified test cases.

Once the manual test cases are reviewed and audited, and their automatability is assessed, the following step is to prioritize them based on their importance and potential impact on the software.

Test cases that have a high impact on the software, are prone to human error or are time-consuming should be prioritized.

Quick Summary:

1️⃣ Reviewing and auditing manual test cases for an automatable state are essential to optimize the testing process.

2️⃣ The process involves identifying manual test cases that meet specific criteria, assessing their automatability, and prioritizing them based on their importance and potential impact on the software.

3️⃣ By identifying and automating manual test cases, organizations can save time, reduce costs, and improve the quality of their software.

Let’s find out why moving to automation is handy:

Steps converting Manual test cases Automated
Steps converting Manual test cases into Automated

The main point

Because you would like to migrate manual cases to automation is the following:

  • It’s easier to track automated percentage status
  • Manual QC/QA prepare cases for Automation QC/QA what they want to automate
  • Moving to automation gets rid of doing routine work for manual engineers, as sometimes syncing manual and automation is problematic.
  • In the future, tests will be cheaper, with fewer issues in production and fewer efforts for manual engineers.
  • Manual can be hybrid QA/QC or completely switch to Automation if they would like to write automation tests.
  • And so on… You can also find other benefits, but I would like to concentrate more on the realization.

Second point

We need to mark test cases that are suitable for automation. It usually has the following steps:

  • Identify the most critical and frequently executed test cases
  • Evaluate the complexity of the test cases
  • Consider the feasibility of automating the test cases
  • Prioritize the test cases based on business requirements and end-user impact
  • Determine the expected ROI (Return on Investment) from automating the test cases
  • Define the scope and goals of the automation effort
  • Create a plan and timeline for automating the test cases
  • Select the appropriate automation tool(s) based on the technology stack and requirements
  • Monitor and report on the test automation progress and results
  • Continuously review and refine the automated test suite to ensure it provides maximum value to the project.

Final point

And last but not least –  let’s find a tool that will fit our needs. Requirements for the tool are the following:

  • It’s popular with a big community to solve issues effectively and quickly
  • Easy to understand for manual QC/QA engineers
  • Simple to sync between manual and automation engineers
  • Fit different programming languages

According to these points above, I would like to suggest a tool named Cucumber. I hope everyone has heard something about it. I wouldn’t like to describe Cucumber at all, as there are a lot of articles about that, for instance below.

Also read to this subject:

What is the feature file and its use in Cucumber?

To use Cucumber, you need to have 2 files: feature and steps.
In the feature file, you will describe the behavior using keywords.

Let’s concentrate more on how to write feature files. First, you need to create a feature_name.feature file. Example:login.feature

Here is an example that Manual QC/QA can write for future automation. Bold text is a keyword that Cucumber uses. It’s necessary to use them in tests.

@admin @login @ui_test @not_automated


Feature: Login as admin
 
  Scenario: Check that user can login to the admin page with valid credentials
    Given I am on the Admin login page 
    When I type the “Admin” username into the “Username” field 
    And I type the “super_secret_password” password into the “Password” field 
    And I click the “Login” button
    Then I should see the “Login success” text


  Scenario: Check that user sees an error message when trying to log in with an invalid password
    Given I am on the Admin login page 
    When I type the “Admin” username into the “Username” field 
    And I type “invalid_password” password to the “Password” field 
    And I click the “Login” button
    Then I should see the “Invalid username or password” text

😀 Looks easy, right?

👉 Now let’s define the steps and expected results for automation and find a reason: Why is it easy to read and automate?

We define each test step in detail, including what needs to be done and what is the expected result. After that, include any data or variables that need to be used in each test step.

Note:

→ Do not forget to make sure the test steps are unambiguous.

→ Expected results for each test step are achievable and measurable.

→ Test steps are in a logical sequence that represents the flow of the scenario being automated.

👇 Now let’s check what is going on here using the first scenario:

@admin @login @ui_test @not_automated
That’s tags. Uses to run specific scenarios with these tags or additional information.

Feature: Login as admin
Feature name. Feature – Cucumber keyword

Scenario: Check that user can log in to the admin page with valid credentials
Scenario name. Scenario – Cucumber keyword

  Given I am on the Admin login page
  Given – Cucumber keyword. The rest of the text is the step name. It’s recommended to start tests with the given keyword. In this step, we should go to the admin login page.

   When I type the “Admin” username into the “Username” field
   When - Cucumber keyword. The rest of the text is the step name. Everything inside quotation marks (“) are parameter. In this step, we type a username.

    And I type “Password” password to the “Password” field
    And - Cucumber keyword. This step looks like the previous one except 
    And keyword, but that does not change our test. In this step, we type the admin’s password.

    And I click the “Login” button. 
    And - Cucumber keyword. The rest of the text is the step name where we click the login button.

   Then I should see the “Login success” text on Admin Page
   Then – Cucumber keyword. It’s recommended to use checks with Then keyword. \n The rest of the text is the step name. In this step, we expect the Login success text on the page.



Automation Engineers will do all the rest and will automate all the steps that were written here in the feature file. The more details there are in the feature file, the easier it will be for automation engineers to automate them.

It’s strongly recommended to sync between AQA/ATQC and QC/QA Engineers to be on the same page (to check if the style looks the same as Automation Engineers expect).

In the future, Manual QA/QC Engineers can also take part in writing automation tests by using already automated steps.

There are a few challenges that you can face 🥲

  • Identify suitable test cases for automation. Start from simple ones!
  • Unstable environment for automation. That means – slow page load, loading screens, etc
  • Deal with dynamic test scenarios and changing requirements
  • Handle exceptions and error scenarios in automation scripts. Automation errors should be easy to read and understandable for stakeholders – why did the test fail?
  • Maintain automation scripts as the application evolves. Always try to think about that beforehand.
  • Manage data for automation scripts and ensure test data validity. Verify that validations work.
  • Train manual testers on how to automate.
  • Ensure the cost-effectiveness and Return on Investment of automation efforts. Sometimes it isn’t worth automating some scenarios. It’s easier to do it manually.

Benefits of migrating manual test cases into automation

  • Efficiency: Automated tests can run faster and more consistently than manual tests, reducing the time and effort required to perform the testing.
  • Accuracy: Automated tests eliminate the risk of human error in manual testing, leading to more reliable and accurate results.
  • Re-usability: Automated tests can be easily reused across different iterations and versions of the application, saving time and effort in regression testing.
  • Scalability: Automated tests can be scaled up to test a large number of scenarios or data sets, making it easier to identify and resolve issues.
  • Cost savings: Automation reduces the need for manual testing, resulting in cost savings for the organization in the long run.

My simple tips to ensure these ones benefits:

→ Define the specific test scenario or use case that will be automated.

→ Break down the test scenario into smaller test steps.

Overall, manual testing should not be completely replaced by automation testing in cases where the test scenario is too complex or requires human intuition and creativity. Certain aspects of testing, such as exploratory testing, cannot be automated and require manual intervention. Automation testing should not be considered a substitute for human involvement in the testing process but rather a complementary tool to enhance the testing process.

Test Automation limitations

The main Test Automation limitations
When automation will not bring outcome?

Automation has become an integral part of software development and testing processes, with a wide range of tools available for automating different aspects of the software development lifecycle. However, despite the many benefits of automation, there are still some limitations to be aware of.

  • One of the main limitations of automation tools is their inability to replicate the full range of human interactions with a software application. While automation tools can simulate user actions like clicking buttons, filling out forms, and navigating between pages, they cannot replicate the full range of human activities such as recognizing and interpreting visual cues, understanding natural language, or adapting to unexpected changes in the application.
  • Another limitation is that automation tools require significant setup and maintenance effort, including developing and maintaining test scripts, configuring test environments, and keeping up with changes in the application under test. It can be particularly challenging in rapidly changing software development environments, where test automation can quickly become outdated or ineffective.
  • Automation tools are not well-suited for all types of testing, such as exploratory testing, usability testing, or testing that requires complex data manipulation or analysis. In these cases, human testers may be better able to identify and respond to unexpected issues or edge cases that automation tools may miss.

Despite these limitations, automation tools remain valuable tools for software development and testing. By automating repetitive and time-consuming tasks, they can help reduce the overall time and cost of software development while improving the quality and consistency of the software product. However, it is essential to be aware of these limitations and to use automation tools strategically as part of a broader testing and development strategy.

In this article, we will not describe how to write steps to do the whole automation work, but that should be enough to start with this solution. Measures can be implemented in any programming language.

The role of QA team collaboration in setting up the process

Overall, involving the entire team is essential for successful software testing. The testing team should not consist only of testers but also developers, business analysts, and other stakeholders. By involving everyone in the testing process, the team can ensure that the application meets the requirements and is of high quality.

Agile team collaboration
Agile Automation implementation

The testing team should work together from the early stages of development to identify potential defects and issues. This collaboration can help prevent bugs from being introduced in the first place rather than just identifying and fixing them later.

Additionally, involving the entire testing team can help create a shared understanding of the application and its functionality. It can improve communication and collaboration between team members and help ensure that everyone is working towards the same goals. By working together and leveraging the expertise of all team members, the team can ensure that the application meets the needs of the business and end-users and is of the highest quality possible.

To involve the entire testing team, it is vital to provide opportunities for everyone to contribute to the testing process. This can include creating test plans, executing test cases, reviewing code, and providing feedback on user interface design.

Hope that helps someone to stop procrastinating and start moving routine work to automation 😀

Create first BDD project
Turn your Jira stories into BDD features as well as test cases into BDD scenarious 👇
Follow us