Quality Assurance Testing with XRAY for Jira

Quality Assurance Testing with Xray and Jira

by with No Comment Atlassiansoftware development

For an IT company it is particularly important to deliver a software product with a high quality. Improving software development processes and automating them is a significant challenge. The software must be constantly tested and the results analyzed in order to quickly identify and eliminate potential errors. A test management solution provides extensive possibilities and advantages to structure and organize the testing of products. In this blog post we give an overview of our own Quality Assurance Test Management, which we have developed with  Xray Test Management for Jira implement.

What is Quality Assurance Testing and what is it for?

Quality Assurance Testing (Software Testing) basically involves the examination of a software product for quality and defects. In a software test, a program is executed with the aim of finding defects due to software errors, collecting information regarding quality and providing an independent view of the software. A test management solution serves as a central tool for managing executed tests as well as for visualizing determined information in the form of a dashboard or report. This gives companies the ability to better assess risks in software implementation. Users of the software are thus assured that they have delivered a product of high quality.

What is tested in the software?

The requirements and functions that are tested vary greatly from project to project. However, 3 general features that are tested can be formulated. These include:

  • Individual functions of a software product
  • Process of installation in a new environment
  • Load Test (simulation of the load on the software)

Why use Jira for Quality Assurance Testing?

Jira is an issue and project tracking software from Atlassianwhich has become very popular in the fields of software development, project management and customer communication. At XALT, we use Jira for bug tracking, planning, managing and documenting work as well as for software development, automation, support and testing. One advantage of Jira is that there is a wide range of apps and plugins that can be integrated and used with Jira. 

Many agile teams use Jira software for their test management because of these extensive capabilities, so that software development and testing remains clearly within one system. At XALT, we take the same approach. We use the plugin Xray Test Management for Jira for this purpose, which offers functions for organization, planning and reporting on the test progress in software test management.

Xray Test Management for Jira

Xray Test Management for Jira is an add-on for Jira that specializes in illustrating and reporting test results. In addition, software developers are further supported in their test management when planning and organizing projects with an increased number of tests and complex test plans. Xray Test Management for Jira is based on Jira and offers in addition to the standard features of Atlassian's software the implementation of a complete test lifecycle including planning, development, execution and reporting. It is also possible to display reports from test reports in interactive diagrams in order to use them for further processing. 

How we use the XRAY for Quality Assurance

At XALT we develop add-ons for Jira, which are derived from the Atlassian Marketplace can be installed. It is particularly important to us that the plugins work error-free. Therefore, we attach great importance to quality assurance and its automation. We develop the so-called UI tests, which simulate user input in browsers to test the user interface and functionality of our software. For the development and evaluation of these tests we use Xray Test Management for Jira.

Example:

Planning:

Quality Assurance Testing with XRAY

For planning the implementation of the test cases we use the test plans from XRAY.

Implementation:

At the beginning, the test cases are written. For our plugins, for example, we most often run UI (=User Interface) tests. For the UI tests we use the Selenium Webdriver framework, which allows the simulation and automation of user input in browsers. To check the function of individual HTML elements, we use JUnit (Java Unit). This is a framework with which unit tests of classes and methods in Java programs can be carried out.

Execution:

The tests are integrated and executed in our CI pipeline (Continuous Integration).

Analysis:

Quality Assurance Testing with XRAY

We then use XRAY to analyze and evaluate the test results. Statistics and diagrams are generated for the test executions, which provide a detailed overview of the successful and failed tests. This gives us as a development team the opportunity to examine the individual test executions more closely.

The individual test runs can also be automated. Automated tests are started when there has been a change in the software. This could be, for example, a new feature, such as the ability to edit the images in our Image Gallery be. If the quality assurance tests were successful, then the change is automatically implemented and a new update can be released. If the test runs are not successful, then we use the XRAY again and examine the results for the errors.

The test results can be presented directly to your customers as diagrams and graphics. In this way, you create the necessary transparency and trust for further successful cooperation.

Conclusion - Quality Assurance Tests with XRAY

The software tests are important to identify errors as quickly as possible and to fix them painlessly. This gives us the opportunity to provide our customers with a consistently high-quality software application. The advantage of XRAY is that a constant test environment is available by means of automatisms and updates are continuously checked for errors.

Technical debt

Technical debt in agile software development

by with One Comment Agilesoftware development

Imagine you are driving a car and you notice that your brakes don't work properly anymore. But instead of repairing them directly, you first decide to wash your car, install a new radio and temporarily repair your brakes with old parts. This way, with your prioritization, the execution of other tasks and the quick & dirty solution, you build up a Technical Debt (Technical Dept). 

Technical debt over time

Sooner or later, however, this approach takes its revenge, since the technical debt does not increase linearly as expected, but exponentially over time. 

By using more and more of these quick & dirty approaches within development, the mountain of debt gets bigger and bigger. This ultimately leads to countless tasks having to be processed in order to solve the problems.

This development is basically also due to the fact that the use of agile working methods and DevOps is increasing the pressure from stakeholders to achieve more in ever shorter periods of time. 

This article will go into more detail about what exactly technical debt is and what causes it. How it affects a product or service. And how to manage it effectively.

What are technical debts?

Whenever unclean paths are taken, a new debt is incurred towards all stakeholders involved. This debt usually becomes visible when systems or software used do not function properly or run unstably. Subsequently, considerable additional effort is required to correct these errors.

This can be further simplified by viewing this debt as the gap between well thought out, designed, developed and tested software and software that is just cobbled together.

How can you recognize technical debt?

  • Lack of or no documentation: Nowadays, work is supposed to be fast and agile. Documentation is often left behind. However, this leads to the fact that usually only a few know what status the project already has. Other or new employees are left out and work stubbornly on it. 
  • We'll deal with it laterSure, projects have to be completed. But as the saying goes, "Get it right, or you'll do it twice".
  • copy and paste from other projects
  • Shortcuts and savings: Quality control and testing are not performed, for example, due to deadlines
  • Bugfix and minor adjustments take longer to implement

What are the causes of the buildup of technical debt?

Lack of vision or concept of the finished software

It should be clear from the beginning what is to be developed. If this is missing, there is very often rework on the design, user interface, architecture or infrastructure. This leads to problems and quality in the code during the entire project.

Missing or inadequate documentation of requirements

Often software requirements are only vaguely or poorly described. This leads to teams and employees not knowing 100 % what exactly is to be achieved. This creates additional workload and thus new technical debt.

Lack of communication and high expectations from management

At the start of a project, with new teams or when working with external service providers, it can happen that expectations of the project team are too high and the first results are to be achieved as quickly as possible. Therefore, it is important to communicate the maximum workload as early as possible and to focus on quality instead of quantity.

Insufficient cooperation between employees

Nowadays, software development usually works with agile methods such as SCRUM. This leads to the assumption that all employees involved have mastered this methodology and can work together right away. This is often not the case and quickly leads to miscommunication and frustration in the team. Tickets get stuck and / or are only sparsely processed. And new issues are added daily.

Bottleneck effect - lack of employees, time and too many tasks as obstacles

It still becomes problematic to reduce the "debt" when employees themselves become the bottleneck in the company. It can often be the case that only a few employees are familiar with systems and know how to maintain them. If these employees are then prevented from working, are ill or, in the worst case, terminate their employment, no one is familiar with the system and a complete standstill occurs. Such a case should be recognized at an early stage and actively tackled.

Change of the technology used or a new version

Every day there are updates that cause changes in the code and approach. As a result, existing code blocks may become obsolete, no longer needed, or cause problems. This has to be fixed in another iteration and again leads to technical debt.

Lack of quality control process

For both small and large teams, quality in code always needs to be checked to see if all the pieces work perfectly together in the end. Lack of quality assurance processes ultimately causes extra work and more tasks to fight problems.

The causes that lead to technical debt being built up can be many and varied. The ones listed here are a first clue to take direct and proactive action.

How can technical debt be dealt with and reduced?

Regardless of how technical debt comes about, there are some recommended actions to proactively avoid its occurrence.

prioritization of tasks

If failures have been identified, they must first be documented and then prioritized. How these omissions are prioritized and addressed ultimately depends on the framework created (team, working method, strategic decisions or the tools used). 

In agile teams, it is usually already the case that the priority of tasks is determined in daily meetings or sprints. Recurring issues and other tickets are therefore usually given a higher priority and processed in a timely manner. In addition, the prioritization of tasks is also determined by the impact of the problem on the company as a whole (e.g. impact on usability, sales or experience) or how important a solution is for the performance of the product or software. The remaining tickets (e.g. irrelevant for the current Sprint) should be stored in the Backlog at the highest position and included in the Sprint in the next meetings. 

Development of a code style guide

A simple way to avoid technical debt is to establish guidelines before the project starts. This should ensure that several different approaches are not used.

Ideally, these should define exactly how code should look. This means, for example, where commas, breaks or brackets must be placed. This offers the additional advantage that the structure and layout of the code are clear.

code refactoring

In the heat of the moment, it can happen that code is written without paying attention to its structure or readability. This makes it difficult to keep track of the progress of the project, fix bugs or implement new features. To get a grip on the situation, code refactoring offers an approach to optimize and revise the existing code step by step.

Tools for the visualization of technical debt

With the help of some tools, omissions or structural problems in the code can be avoided right from the start or at least checked and optimized afterwards. One of them is SonarQube.

This tool analyzes your code for quality, security, and indicates where code segments are duplicated, for example. Furthermore, it gives a time estimate of how long it takes to reduce technical debt within the code.

SonarQube provides the ability to detect future technical debt during the software build process and can be configured to give builds a "failed" status if the technical debt is too large.

Do not allow individual code ownership

As mentioned above, it is not a good idea to have only one or a few person(s)/developer(s) responsible (and irreplaceable) for important system. If there is a problem with the web application, the code owner is the person who has to fix it. Code ownership is bad for code owners because it stunts their and the company's growth. Also, code ownership causes problems for the organization and for the code owners. If no one knows how a system works, no one can give effective code reviews. Worse, the code may not be reviewed at all.

When the team is responsible for the code, everyone can help make design decisions. Everyone can participate in the system design discussion, contribute ideas, and share responsibility for those decisions. Further, it's no longer such a big deal if an employee is no longer involved in the project or is sick. 

Summary

One must be aware that "technical debt" initially offers no obvious and tangible added value and it takes time to reduce it. Furthermore, most results will only become measurable and visible over time. However, this does not mean lying on one's lazy skin and hoping for the best. In the end, you should ask yourself for which debts it makes sense to reduce, which ones have the biggest impact on business or economic factors and which ones would have no impact at all.