How to organize tests in Jira?

[#1]

While software testing guards the quality of the end-product, test management is what controls the whole process and ensures that it succeeds. Putting it in this context, makes one thing clear - transparency is the most important aspect of managing tests, especially in the specific, fast-paced environments of Agile teams. 

Tools like Jira and test management add-ons equip QA teams for this battle, however most of them have one bottleneck - they impose a rigid framework of the testing process. As a variety of QA strategies exist, there’s no model that fits them all, it always needs to be adjustable. So the questions are: how could the testing process look like if flexibility was a part of a test management tool? And secondly, how QA teams would organize their tests in Jira?

Testing process at scale - small, medium and enterprise models

There are two main factors that shape the final outlook of the testing process: the scale and the amount of people involved. Keeping that in mind, scenarios at three levels can be distinguished - small, medium and large, enterprise-like processes. 

• Small projects:

At the first level, small projects usually engage a smaller team, where each member takes cross-functional roles. At the basis, the testing group is made out of test engineers, who design test cases, execute them and later on, gather defects. A person who is responsible for defining a project's scope, also takes part in requirements definition - it can be a project manager, but also an outside stakeholder. However, the main responsibilities still fall on the small testing team. 

• Medium-sized processes:

Medium-scale strategies come with expansion of teams in terms of roles and separation of duties. Suddenly, it’s not just a QA engineer against the whole cycle - employees from other teams get involved. Product owners or business analysts appear at the stage of defining requirements, they may also track the progress at later phases. New roles emerge within the QA team, such as test designer, whose sole responsibility is test case design. Their execution and reporting defects becomes a duty of QA engineers. While the division of tasks becomes clearer, members juggling multiple tasks are still common. 

• Enterprise level:

The enterprise scale of the testing process calls for the highest level of duties separation, as the setup expands and becomes more fragmented. Test analysts, consultants, architects - these are just examples of new members of the QA team. Each phase is controlled by a person with a specialized role, which documents every step. 

Non-negotiables of test management: visibility and communication

Despite the vast differences at every scale-level, there is a common ground: visibility and clarity are necessities. Responsibilities have to be clearly defined, knowledge must be accessible for the interested parties and communication needs to be at the top-notch level. There’s no space for chaos, organization is of utmost importance, as it can make or break the test management process. So what approaches can be taken when organizing tests in Jira? Four methods are described below as examples, however the truth is that possibilities are endless. 

All-in-one method - a unified testing workspace

In an all-in-one approach, everything is grouped together in one project - from requirements to defects. The Jira board can be further configured to provide a clear division of testing elements on a project’s board (e.g. by introducing swimlanes). While it is the simplest setup, small or early-stage QA teams can benefit from it the most. In such teams, test engineers usually take up multiple roles and every team member is involved at each step of the process, so visibility of all elements is a must. By grouping every element in one project, a quick overview is not the problem. This approach is also one of the easiest to set-up and maintain standards. What’s worth adding, is that in most situations, these simple processes are not heavily formalized.  So teams may work with team-managed Jira projects, where each group works on their own project. Utilizing company-managed projects is another step unification of the QA strategy and teams’ work resembles more an organization.

Nevertheless, simplicity is a two-edged sword - what works for smaller processes, becomes problematic once scaled. Here, everyone sees everything - so if the QA process expands and duties are separated across more distinct roles, then chaos is inevitable. High volume of work items on the board leads to clutter and confusion. As a result, testers may struggle to find the right execution or get lost in defect entries and execution logs, while scanning for requirement coverage.

Separate projects model - readiness for scaling

While this next approach is undoubtedly too segmented for smaller scale processes, it can become a saviour at the large scale - the separate projects method, where each testing element is allocated in an individual project. With this model, scaling the process and chaotic boards aren’t issues - as each of the elements is treated like a separate entity. This division of elements can also prove itself useful in regulated branches, such as healthcare, banking or aerospace, where formal documentation and audits are crucial parts of software testing. So, what kind of opportunities does this method create?

As it was mentioned, enterprise-level processes are made up of not only QA engineers - there, each step of the strategy can be controlled by a variety of employees from different departments. Together, they need to be able to smoothly collaborate in order to deliver the best results. This method gives each team member with a specific role a chance to focus strictly on their responsibilities, all while allowing them to work simultaneously. For example, product owners and business analysts can refine requirements, test managers carefully create test plans, while the rest of the QA team prepares test cases. Such a model is especially useful, when different project permissions are needed - it allows to clearly define the abilities of team-members. Business owners may only be able to edit requirements in a set project, whereas QA teams can only access it to browse through. This method also makes it easier to clearly show who is accountable for which tasks and track the progress. Thanks to the high-level of separation, each project can be adjusted to its needs - customized workflows may be added, as well as approval processes (such as test case acceptance). However, as the QA process expands, having access to every detail and seeing real-time updates can be more overwhelming than helpful. Separation into projects gives an opportunity to decide what knowledge should be accessible and to whom, as a result allowing each team to focus on matters of the most importance. 

Despite many benefits brought by this organizational model, there is one key aspect to be kept in mind - those who manage this strategy need to be really strict with governing and naming all contents within projects. Each team member involved should know the main points of the strategy and follow the internal naming convention. If done otherwise, this method may cause more damage than good. 

Balanced options for mid-scale teams

But what if the testing process is at the middle scale? The all-in-one approach may be insufficient and organization of each element into individual projects may be overly complex. Here, test-centric or design-focused methods could turn out to be the most useful. Both of these models are variations of the separate projects configuration, as they focus on grouping test elements accordingly, but they are not as extensive.

Test-centric setup for Agile collaboration

In a test-centric method, requirements and defects are collected in individual software projects, while the rest of the testing elements (test cases, test plans, test executions) stay in one project. This approach can work perfectly for cross-functional testing teams, where the same members handle multiple phases of the test lifecycle, whereas people from different groups are engaged in requirements definition and defects collection. Product or business owners can easily collaborate with testers to define requirements and manage them in one project. The QA team benefits from grouping test cases, test plans and test execution together - they can quickly share feedback and coordinate their efforts faster. By managing test elements in one folder, they navigate easier between each one. Later, the defects are collected in a separate project, which is accessible for developers - this way testers can clearly share valuable information. While this approach could be deemed as difficult and problematic in multi-level QA environments that require heavy documentation, it is a perfect fit for fast-paced processes, where the testing lifecycle is short and iterative. 

Design-focused model for alignment with test lifecycle

While the model described above divides requirements and defects, the design-focused option separates the testing elements into three groups: design, execution and defects, naturally aligning with the testing lifecycle. By taking this route, teams clearly separate the QA stages from one another and can avoid mixing data, such as planning documents with execution results. In this scenario, the QA team may create subgroups which are specified in each stage of the testing process - one team is responsible for test design, while the other - for execution. Similarly to above, the design phase engages people like business owners during requirement definition, the testing teams may support them. The QA manager along with test engineers design test cases and form test plans. Later on, the test cases are executed by the second testing team. At the final stages, developers can access defects in a separate project. This model allows to clearly define handoffs between groups without causing any confusion, fostering a collaborative environment. 

Why flexibility of testing setup is key and how does Appsvio Test Management deliver it?

After a deeper dive into each of the exemplary organization models, it’s easier to understand that having the possibility of choice and customization while configuring a testing strategy in Jira is fundamental. This level of flexibility is what makes Appsvio Test Management (ATM) app stand out among others on the Atlassian Marketplace. The configuration of the Testing Setup is straightforward, transparent and most importantly - adjustable. This way, ATM can become a universal test management extension for testing processes of any size - no matter how small or large they turn out to be. Additionally, the add-on gives the users a chance to track requirements and defects in Jira, making it a complete command center for testing. As the tool is based fully on Forge and hosted on the Atlassian infrastructure, ATM makes test management an integral part of Jira and utilizes native elements, such as work items or workflows.

As the QA processes will continue to evolve, an organizational model that is one-size-fits-all is just a fantasy. The testing teams need tools that can enhance their work and offer a multitude of options - Appsvio Test Management (ATM) makes that possible. Whether it’s a small start of the process or a complex enterprise-level strategy, ATM supports its users at every scale by adapting to their needs. 

ATM is available on Atlassian Marketplace now. 

If the topic of test organization piques your interest, watch our webinar, where we dived deeper into the use cases and answered your questions!

Watch the session here.