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:
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 đą