Automated Test Cases Creation and Maintenance

For a QA/automation engineer, one of the most painful points is to write manual test case and then the test maintenance in JIRA/Excel or some test case management tool 😥

There can be several reasons to write manual test cases:

• ISO audits requirement.
• Sharing with business stakeholders.
• Clients ask for compliance purposes.
• Sharing between multiple projects.

When it comes to automating these test cases, most people write them again in the form of feature files (BDD framework approach), which brings the duplication of the efforts thus increasing the overall project timeframe ⌚

Now imagine, if someone comes and tells you that you don’t have to write those manual test cases or maintain those clumsy Excel sheets, you just focus on your automation. Isn’t this a big relief? For instance:

Manual test case	Automation test case (BDD)
Feature: Login functionality Scenario 1: Successful login Execution Steps: Enter valid credentials Click login button The user will see the homepage Scenario 2 and so on…	Feature: Login functionality Scenario: Verify the successful login scenario Given a user enters “abc” username in the user field And the user enters “xyz” password in the password field The user clicks on the login button Then the user should be able to successfully log in

If you notice, in both cases the person is telling one and the same thing. So why can’t we use the feature file scenarios as manual test cases themselves? Now we are thinking in the right direction. But before jumping to the solution let’s list down the issues that can come up in this approach 🧐

Challenges with this Approach

• Distinguishing between manual and automated test cases.
• Automation happens in a progressive manner, not on day 1.
• Maintaining the execution status of the test cases.
• Making the test cases available to the end-user as feature files are part of the automation code repo, kept somewhere in SCM (Git).

Here enters the automated test case creation utility, which takes care of all the above-mentioned issues ✅

Tools Used

Test case management tool: Jira (It’s market de facto for project management).

Testing framework: Cucumber (For readable test cases).

Wrapper framework: Serenity BDD (Because of its compatibility with JIRA and its inhouse reporting).

The utility consists of 3 parts

• Tag-based hook’s functionality of Cucumber which gets the context of the scenarios and features files.
• Jira Rest APIs to create JIRA test cases we extracted in the previous step.
• Writing back the generated JIRA IDs to the test scenarios for future reference.

Let’s understand it in a simple flow diagram

 

Source: Test Case Automation

As explained above we will use the hooks capability of cucumber to orchestrate our automation.

First use case: When you want your BDD feature files and scenarios to be created in JIRA for the first time, tag your feature file with @TBC tag. It will automatically create a corresponding JIRA ticket test feature –> test case, along with this, it will update your test case feature file with @JIRA:ID for future reference.

@TBC @JIRA:CM-12
Feature: Verify login flow

  Scenario: Verify successfull login
    Given user enter right username and password
    When user click on login button
    Then user be able to succesfully login

@After("@TBC")
   public void jira(Scenario scenario) throws IOException, URISyntaxException {
       TestCase testCase = new TestCase();
       testCase.testCaseCreation(scenario);
   }

Second use case: Let’s say you have changed your existing test case and want to update the same in JIRA. Just tag your feature file with an additional @TBU tag. It will update the corresponding JIRA test case whose JIRA ID was created previously.

@TBU @JIRA:CM-13
Scenario: Verify failed login
    Given user enter wrong username and password
    When user click on login button
    Then user should not be able to login

@After("@TBU")
    public void jiraUpdate(Scenario scenario) throws URISyntaxException, IOException {
        TestCase testCase = new TestCase();
        testCase.testCaseUpdation(scenario);
    }

Manual test case: For manual test cases give the additional tag @manual on the feature level. It will update the created JIRA test case with an automated: false custom field of JIRA.

@manual
Scenario: Verify failed login
    Given user enter wrong username and password
    When user click on login button
    Then user should not be able to login

Note: This Utility is not restricted to the above implementation. Unless you get the gist, then it can easily be modified according to your use case.

Conclusion 

Though this utility seems to be very small, it solves a couple of problems for a QA/automation engineer:

• Your efforts are reduced by half and you can focus more on automation rather than on manual test case creation.
• Your documentation is all done, no need to worry about a last-minute hush rush for compliance/audits.
• Jira will maintain a proper audit trail for the test cases as it records even the slightest change in the ticket.
• Functionality-wise test cases creation means having logical separation.
• Tracking manual as well as automated test cases.

Hope you enjoyed this article 😊
If you have any insights or questions leave them in the comments section 💢