Test Authoring Best practices for QMetry Test Management for JIRA
QMetry Test Management for JIRA has been designed for Agile Development & Testing teams.
Goal is to bring together awesome team and help them collaborate. In this document, we will highlight how agile teams with diversified and specialized roles can come together and make great software products.
Let’s take a typical scenario where your team comprises of various roles like
Product Owner / Project Manager
Our goal is to build a portal that allows end users to make a flight reservation for a reputed airline “FlyHigh”.
After intense market research and due-diligence, Product owner and stake holders come up with high level requirements which would be usually treated as Epics or Stories in JIRA.
In our case, those stories could be:
As a flyer, I should be able to search flights.
As a flyer, I should be able to customize my journey and compare options.
As a flyer, I should be able to enroll and benefit from Loyalty Program.
As a flyer, I should able to book flights and manage my journey later.
Typically a Product Owner/ Stake holders provide these high level requirements for teams to get started.
Best Practice Tip: We usually recommend is Test Acceptance Driven Development.
Right inside your story, you can start putting Test Acceptance criteria as shown below. Usually this is done by a Business Analyst or Lead Tester.
For Development teams, it is a Requirement repository with readily available standards to refer. When validations are well defined, it brings more clarity to developers.
The written Test Cases build up a common ground between developers and testers.
As you might have realized, we are in the midst of most critical activity, Test Authoring.
If done right, Test Authoring can improve visibility, ensure traceability, reduce maintenance and layout foundation of comprehensive regression suite, ultimately leading to great quality products.
Here are some of our recommendations on Test Authoring Best Practices:
Define self-sufficient, modular, reusable Test Cases
Clone Test Assets
Use Test Scenarios
1. Define self-sufficient, modular, reusable Test Cases
Test case is the foundation unit for Test Authoring. Think of test case as one single atomic activity (with group of actions that end users need to perform) that achieves unique functional goal.
In our case, Story 3 and Story 4 require a flyer to benefit from Loyalty Program or create/manage bookings. Both of these stories, need user to login. If it’s a new flyer, we expect them to register and login before they can avail these features. Let’s see how we can design Test Artifacts to best suit our needs.
Test Cases of Story 3 related to Loyalty Program would look like this.
Test Case 1: Validate that a flyer is able to login.
Test Case 2: Flyer should be able to review Loyalty Program benefits after login
Test Case 3: Flyer can encash Loyalty Program benefits once he earns above 500 points.
Test Cases of Story 4 related to bookings would look like this.
Test Case 1: Validate that a flyer is able to login.
Test Case 2: Search for flights
Test Case 3: Make a payment.
Test Case 4: View Reservation.
Kindly note that Test Case 1 related to login is common in both stories. It makes all sense to reuse this test case to improve efficiency and reduce maintenance effort.
As shown in the case above, Test cases should usually tie to functional actions that user performs to achieve meaningful outcome. That helps in modularity and reusability.
Screen shot below shows you how to reuse this test case.
“Validate that a flyer is able to log in” test case already exists for Story 3 above. We can reuse the same test case for Story 4 below.
Reusing test assets in the event of repetitive user actions, saves human efforts and keeps test artifacts in sync across the test documentation.
Now that we have learnt how to define Test Cases, let’s put more details inside Test Case via Test Steps.
2. Clone Test Assets
We highly recommend reuse of Test Cases. However there would be scenarios where reuse might not make sense. Let’s take an example here.
Login is a reusable Test case; however, login from mobile phone achieves logically same outcome but the internal flow is different where user should create one time token to use mobile app for FlyHigh airlines.
In this case, I would clone Test Case 1 “Login” and duplicate it as “Login from a mobile phone”.
Cloning breaks reusability. However, it gives original Login Test Case Template for me to modify so I don’t have to author a test case from scratch.
On cloning a test case, it creates a replica of it as shown below.
The copy of test case can be renamed and the test case template with test steps can be reused.
Similarly, cloning can prove a better option for performing Regression Testing when multiple builds are released by development team and are handed over to QA team for testing.
3. Use Test Scenarios
Another best practice we recommend is using Test Scenarios. In our case, here are couple of Test Scenarios I could imagine of.
Validate Loyalty Program from Mobile Phone
Validate Loyalty Program from Computer browser
Now, I would associate relevant Test Cases with these individual Test Scenarios.
These Test Scenarios can then be executed against Platforms (i.e. environment) best suitable to them. Platforms are defined while creating Test Runs for different stories, test scenarios, and test cases.
4. Shift Left with Automation
Consider all possible scenarios while constructing automation script for automated test cases. Well written manual test cases provide a strong base for automation. It also helps Automation engineers write quality code and streamline automation script with manual test cases.
It might be a great idea to link automation test cases which usually exists outside in code repository with manual tests created inside JIRA. Ability to link them could be very helpful as shown in below example.