Every organization is unique in its own way. Different workflows, niche use cases, and specific types of work culture are creating a one of a kind landscape that oftentimes requires more than just the default options to thrive. Test management is one of many areas where tool customization plays a significant role in creating an effective and efficient work environment that is capable of honoring the distinctive qualities of the organization.
In this article we will focus on one specific element that can open up a whole new world of possibilities when customized, and that is test execution status. Join us, while we explore the many ways in which custom test execution statuses can transform your testing and accommodate the unique needs of your organization.
Testing is an organic part of the product development life cycle. It is closely tied to other phases of the development process. And, just like these other phases, testing too is full of nuances and can hardly ever be contained within generic statuses such as Passed or Failed. Creating custom statuses that reflect your specific needs can not only be more effective, but also directly translate into a higher comfort of use for your testers. After all, it’s the app that should serve the users, not the other way around.
Ideas:
Blocked: Indicates that the test cannot proceed due to an external dependency or issue.
Deferred: Signifies that the test execution is postponed to a later date, possibly due to lower priority.
In Progress: Shows that the test case is currently being executed.
Finding bugs is the whole purpose of testing. However, not all bugs are equally critical. They can also be caused by different factors and it’s important to know where to look for the source of the issue in order to resolve it as soon as possible. Therefore, marking all failed tests with the same Failed status might be a missed opportunity. By specifying the nature of the problem within the execution status name, we can facilitate quicker resolution.
Ideas:
Failed - Environment Issue: Differentiates between test failures caused by environmental issues rather than defects in the code.
Failed - Known Bug: Indicates that the failure is due to a bug that is already logged and acknowledged.
Oftentimes testing can be dependent on many other factors than just the technical ones. For instance, in industries with strict compliance and regulatory requirements it can happen that testing cannot progress without a specific approval. Custom statuses can be helpful in managing such cases and ensuring all necessary regulations are ingrained into the testing process.
Ideas:
Not Applicable: Used for test cases that are not relevant under certain regulatory conditions or in specific environments.
Pending Approval: Indicates that the test case execution results need managerial or regulatory approval before proceeding.
It goes without saying that communication is one of the things that can make or break the team’s effectiveness. No matter how highly skilled the developers and testers are and how much they know about their respective areas of expertise, if proper communication structures are not in place, they will struggle to work together effectively. Custom statuses allow you to create a set of execution statuses perfectly aligned with the specific needs of your organization, and reflecting the individualistic language of communication that will serve both developers and testers.
Ideas:
Under Investigation: Signals that a test failure is being analyzed by the QA team.
Waiting for Dev Fix: Indicates that the test case is blocked due to pending fixes from the development team.
In some cases, the key information is which test cases should be executed first, and which can be tackled as the 2nd priority. It can be especially useful for project managers and team leads, since it helps them allocate resources more efficiently.
Ideas:
High Priority: Marks test cases that are critical and need immediate attention.
Low Priority: Indicates test cases that are less critical and can be addressed later.
UAT is a phase of software development in which the product is tested by the end-user in order to verify whether it will meet the requirements of the intended audience. Since UAT involves 3rd party actors, it is highly important that the current status of testing is carefully monitored and documented. Custom statuses can be used to reflect the feedback and approval status from end-users or stakeholders.
Ideas:
Awaiting User Feedback: The test results are pending feedback from end-users.
Rejected by User: Indicates that the test results or functionality were not accepted by the user.
Regression testing is a distinct part of the testing process, and as such it needs to be easy to identify when looking at the test case executions. When mixed with other executions it can get lost in the crowd. To save time and energy, it is better to mark regression testing executions with dedicated custom statuses so that they are clearly visible right off the bat.
Ideas:
Regression Passed: The test case has passed regression testing.
Regression Failed: The test case has failed during regression testing.
Not every testing process looks the same, and sometimes conventional statuses are incapable of covering your unique case. In exploratory testing, where the testing is more dynamic and less structured, custom statuses can be a game changer. Creating your own statuses gives you freedom and flexibility in applying the labels you require in your testing.
Ideas:
Exploratory - Needs Review: Results from exploratory testing that require further analysis.
Exploratory - Insights Logged: Indicates that insights or potential issues were logged during exploratory testing.
Integration testing is yet another type of testing that might require its own statuses in order to be easily distinguishable from other types of test case executions. Custom statuses can help identify issues related to system integration points.
Ideas:
Integration Success: The test case passed all integration points.
Integration Failure: The test case failed at an integration point.
More effective communication and cooperation between developers and testers, although significant, are not the only assets of custom statuses. Crucial information included in the statuses will be also reflected in the reports that you can use to better understand the progress of your testing, as well as share with the stakeholders in order to demonstrate the comprehensive overview of the team’s work.
To add even more depth to the custom statuses, some apps for Jira, such as QAlity Plus - Test Management, offer additional features allowing you to choose how you want each of the custom statuses to be treated by the app and displayed in the reports.
Idea:
Status: Passed with issues
Status type: Passed
Can be used when all crucial elements of a test case execution are passed, but there is a minor issue still to be fixed, e.g. a typo. In such a case the test execution will be treated by the app as Passed and not held back by a low priority bug, while at the same time the team will be aware of the issue that still needs to be taken care of.
Summary
The above ideas are just examples of use cases that can be modified and played with. The beauty of custom statuses is the endless possibilities. It is a simple feature that by a small cost of effort can boost the effectiveness of your testing, improve communication between teams and with stakeholders, and help you make your testing process truly aligned with the unique needs of your organization.
For more useful insights check out our other article on the topic: How to manage custom test case execution statuses in QAlity Plus.
Kinga -SolDevelo-
0 comments