• Skip to main content
EuroSTAR 2027 - Sign up for early access

EuroSTAR Conference

Europe's Largest Software Testing Conference.

  • Programme
    • Call for Speakers
    • 2026 Programme
    • Community Hub
    • Awards
  • Attend
    • Why Attend
    • Bring your Team
    • Testimonials
  • Sponsor
    • Sponsor Opportunities
    • Sponsor Testimonials
  • About
    • About Us
    • Our Timeline
    • FAQ
    • Blog
    • Organisations
    • Contact Us
  • Book Now

EuroSTAR Expo

Agentic Automation in Testing: Smarter Workflows, Faster Results

April 7, 2025 by Aishling Warde

In modern software development, outdated QA processes often struggle to keep up with the necessity for reliability, accuracy, scalability, and speed. Manual testing is tedious and too slow, while rigid automated test frameworks demand constant maintenance. This is where Agentic Automation gained prominence. Agentic AI is revolutionizing QA with AI-driven, self-adapting workflows that autonomously analyse, learn, and optimize test processes.

This shift towards Agentic Automation guarantees smart decisions, higher test efficiency, optimized test execution, and smooth incorporation with modern CI/CD pipelines.

As companies push for seamless digital experiences and faster release cycles, embracing Agentic Process Automation is no longer a choice—it’s a requirement. Let us discover how this innovative approach revolutionizes QA with smarter, quicker test execution.

What is Agentic Automation in Testing?

Agentic Automation denotes a quantum leap from traditional automation testing. Unlike conventional test frameworks that depend on manual oversight and predefined scripts, Agentic AI test works autonomously, making intelligent decisions based on actual data.

Unlike deterministic automation that strictly follows predefined workflows such as RPA (Robotic Process Automation), Agentic Automation leverages modern ML (machine learning) algorithms and LLMs (Large language models) to scrutinize patterns, adapt to growing test environments and smartly optimize test strategies.

Crucial Traits of Agentic Automation:

  • Self-Healing Testing Scripts – Self-heals broken tests caused by code or User Interface (UI) changes.
  • Self-Learning & Adaptive Tests – Agentic process Automation continuously refines test cases based on past implementation results.
  • Predictive Error Detection – Detects potential glitches before they impact production.
  • Continuous Optimization – Enhances test performance using data-driven insights.
  • Autonomous Test Implementation – Executes testing strategically through risk-based prioritization.

How Agentic Automation Drives Smarter, Faster Testing Workflows?

Agentic Automation is revolutionizing quality assurance (QA) by applying Agentic Process Automation, Agentic AI, and Agentic Workflows to deliver self-healing, self-learning, autonomous test systems. This transition helps businesses minimize human effort, increase the pace of test execution, and improve the entire software quality.

  1. AI-Centric Self-Healing for Reliable Automated Testing

One of the major challenges in traditional automation testing is test maintenance. Slight modifications or code updates can disrupt automated scripts, demanding persistent manual fixes. Agentic Automation addresses this issue with self-healing capabilities. AI detects UI or application logic changes and dynamically updates test scripts, ensuring seamless execution and improved reliability.

  1. Intelligent Test Prioritization for Speed & Productivity

Test cases differ in significance. Rather than executing every single test indiscriminately, Agentic Process Automation intelligently prioritizes them using past failures, risk assessment, and impact analysis. This confirms critical functionalities are tested first, accelerating feedback loops and reducing delays.

  1. Predictive Analytics for Early Error Identification

Traditional testing is reactive—errors are identified and fixed after implementation. Agentic Automation transforms this method using predictive analytics to find potential failures early in the SDLC. By scrutinizing previous test data and production logs, AI can forecast defect-prone areas, enabling QA teams to take proactive measures.

  1. Smooth Cross-Platform & Cross-Browser Tests

Guaranteeing software compatibility across various settings—such as Safari, MS Edge, Chrome, and mobile devices—is a daunting challenge. Agentic Automation optimizes cross-browser tests by intelligently choosing the most effective test configurations, ensuring thorough coverage while eliminating redundant executions.

  1. Incorporation with CI/CD Pipelines for Continuous Tests

Modern DevOps practices demand smooth CI/CD incorporation. Agentic process Automation impeccably incorporates tools such as Azure DevOps, GitHub Actions, GitLab, and Jenkins, allowing continuous testing at every development phase. This enables speedy deployments, mitigates risk, and improves the software delivery pipeline.

Why Businesses Need to Adopt Agentic Automation Now?

Gartner has named Agentic AI one of the top technology trends for the year 2025. By 2028, 33% of enterprise software will integrate Agentic AI and around 15 percent of day-to-day work decisions will be made autonomously. This significant move denotes a fundamental change in how enterprises operate—moving towards automation that thinks, accepts, and progresses in real-time.

Image Source

Businesses that embrace Agentic AI can also experience the following:

  • 80% reduction in test maintenance efforts through AI-powered self-healing.
  • Lower defect escape rates through advanced predictive defect identification.
  • Better scalability and test coverage across multiple devices and platforms.

With rising demand for higher software quality and faster releases, companies that overlook Agentic process Automation may fall behind in speed, agility, and quality.

ACCELQ Autopilot – AI-Driven Agentic Automation at Hyper speed

ACCELQ’s Autopilot represents a sophisticated implementation of generative AI in test automation that goes beyond basic script generation. It offers an interconnected suite of AI capabilities that work together to transform how teams create, maintain, and scale their test automation.

At its core, Autopilot combines multiple intelligent features that address the fundamental challenges in test automation:

  • Scenario Discovery and Test Step Generator
    • Automatically creates comprehensive test scenarios and detailed test steps from – simple business descriptions.
    • Understands both UI and API testing needs.
  • AI Designer for Modularity
    • Intelligently structures test into reusable components.
    • Ensures tests are built as maintainable assets rather than isolated scripts.
  • Test Case Generator
    • Creates diverse test combinations that cover various business scenarios.
    • Automatically populates relevant test data while maintaining logical relationships.
  • Logic Insights
    • Provides contextual understanding and optimization suggestions.
    • Embeds test architecture expertise into the tool.
  • Autonomous Healing
    • Automatically adapts to application changes, even handling complex modifications like element type changes.
    • Provides AI-augmented troubleshooting support.

What makes this offering particularly noteworthy is how these features work together cohesively – from initial test creation through maintenance and optimization – while keeping the interface intuitive for both technical and non-technical users. It’s smarter than it sounds — the system knows much about what makes a good test. It forcibly applies best practices requiring years of experience to do manually around things like reusability, maintainability, and reliability.

Though the immediate focus of this multi-pronged approach to integrating AI at the core of test automation is about faster test creation, this offering also promisingly tackles longer-term challenges such as test maintenance, scalability, and adaption to change, making it one of the strongest candidates for enterprises keen on rolling out sustainable AI-powered test automation at scale.

By removing the old bottlenecks associated with script maintenance and test flakiness, Autopilot allows test automation to be a development enabler instead of a maintenance burden. With its deep integration of generative AI, businesses can achieve continuous testing with minimal manual intervention, accelerating release cycles while maintaining high-quality standards.

Final Thoughts

As organizations progressively adopt agile methodologies, Agentic AI emerges as a boon, fostering smarter, faster, and more adaptive software development. By embracing Agentic Automation, companies can optimize workflows, accelerate test execution, reduce costs, and stay competitive. Those who hesitate risk disorganization, delays, and falling behind in an ever-growing landscape.

To stay ahead, businesses must embrace Agentic Process Automation and shift towards AI-centric, adaptive test strategies. The future of QA is proactive, intelligent, and self-sustaining —the time to embrace it is now.

What’s holding you back? Step into the future of test automation now! Connect with our experts now and supercharge your test workflows.

Author

Geosley Andrades, Sr. Director, Product Evangelist at ACCELQ

Geosley is a Test Automation Enthusiast and Community builder at ACCELQ. Geosley helps ACCELQ with innovative solutions to transform test automation to be simpler, more reliable, and sustainable for the real world. He is also involved in actively shaping ACCELQ’s vision, immersing himself in comprehensive competitive analysis, industry analyst relationships, and pioneering research endeavours.



ACCELQ were Exhibitors at EuroSTAR 2025. Join us at EuroSTAR Conference in Oslo 15-18 June 2026.

Filed Under: Big Data, EuroSTAR Expo Tagged With: software testing conference

Are You Really Agile? Self-Asses If Your QA Team Is Truly Agile

March 31, 2025 by Aishling Warde

Adopting Agile practices doesn’t automatically mean your QA team is working in an Agile way. Many teams follow the structure of Agile like sprints and retrospectives, but still struggle to fully embrace Agile principles. True agility in QA is about flexibility, continuous improvement, and deep collaboration to ensure quality at every stage of development.

Many teams find themselves wondering: Are we really Agile, or just following a checklist of Agile rituals? That’s the exact question explored in our ebook, “Are You Really Agile? A Practical Guide for QA Teams.”

In this article, we’ll explore key insights from the ebook to help you assess your QA team’s Agile maturity and share practical strategies to strengthen your processes.

Signs That You’re Not Truly Agile

These are the most common indicators that suggest your team is not Agile:

1.Inflexible Processes
Agile is meant to be iterative, yet some QA teams still rely on rigid, step-by-step workflows that don’t leave room for adaptation. If your testing approach isn’t flexible enough to accommodate changing requirements, it may be limiting your agility.

2.Communication Silos
Agile emphasizes ongoing collaboration, but if QA and development teams rarely interact outside of sprint reviews or retrospectives, valuable discussions may be missed. Continuous alignment is key to delivering high-quality software efficiently.

3.Lack of Continuous Feedback
In Agile, testing and feedback should happen throughout the sprint, not just toward the end. If your team is catching defects late in the cycle rather than identifying issues early, your process might be more reactive than proactive.

4.Testing as a Separate Phase
Testing should be seamlessly integrated into development, not treated as a final step before release. If QA still operates as a standalone phase rather than being part of the sprint’s workflow, it’s a sign that your team hasn’t fully embraced Agile testing.

Take This Self-Assessment to Know If You Are Truly Agile!

To help you evaluate how Agile your QA processes really are, we’ve designed a straightforward self-assessment questionnaire. It allows you to analyze your workflows, collaboration, and testing practices to see where your team stands on the Agile spectrum.

How it works: Rate your team on a scale from 1 to 5, with 1 meaning “Never” and 5 meaning “Always.”

CategoryAssessment QuestionScore (1-5)
Flexibility in ProcessesDo your QA and development processes allow frequent changes?
Are test cases and schedules adaptable as features change?
Early Involvement of QA (Shift-Left Testing)Is QA involved from the beginning, refining user stories?
Are test cases planned in parallel with feature development?
Collaboration Between QA and DevelopersDo QA and developers work closely together during sprints?
Is there ongoing communication between QA and developers?
Continuous Feedback LoopsAre feedback loops frequent during the sprint?
Is feedback (and bugs) from the testing team assessed and addressed quickly?
Automation in TestingDo you generate automation for the stories being developed during the sprint (vs automated on later sprints)?
Are automated tests run for each significant code change?
Test Case Reusability and MaintenanceIs your test library modular and easy to maintain?
Are automated tests regularly updated?
Defect Management and PrioritizationAre defects prioritized and resolved within the sprint?
Are there clear criteria for classifying defects?
Continuous Improvement and RetrospectivesAre QA processes included in sprint retrospectives?
Are metrics used to drive continuous improvement?

After completing the self-assessment, review your total score to understand where your team stands in Agile maturity:

  • 35 – 40: Your QA team is highly Agile, effectively embracing flexibility, collaboration, and continuous improvement.
  • 25 – 34: You’re heading in the right direction, but there’s room to improve. Identify lower-scoring areas and apply the strategies in this guide to strengthen your Agile approach.
  • 15 – 24: While some Agile practices are in place, there are noticeable gaps in your QA processes. It’s time to rethink your approach to collaboration, feedback loops, and integrating testing throughout the sprint.
  • Below 15: Your team may be Agile in name only. Consider revisiting Agile fundamentals and restructuring your QA processes to align with core Agile principles.

3 Key Strategies to Maximize QA Efficiency in Agile

  1. Shift-Left Testing

A core Agile principle is embedding QA early in the development process. However, many teams still follow outdated habits, treating testing as an afterthought rather than an integral part of the sprint. This delay often results in defects being discovered late, leading to costly rework, missed deadlines, and misaligned expectations.

Best Practice: Establish a continuous feedback loop between product owners, developers, and QA from the initial requirement discussions. Ensuring clear acceptance criteria and well-defined testable requirements helps prevent last-minute surprises.

Practical Tip 1: Use tools like mind maps or flow diagrams to visualize user journeys, dependencies, and potential risks during requirement gathering. This helps teams proactively identify edge cases and improve test coverage.

Practical Tip 2: Implement Behavior-Driven Development (BDD) to foster collaboration between QA, developers, and product owners. Writing test scenarios in plain language ensures shared understanding and helps translate requirements directly into test cases.

  1. Defect Management & Resolution

In Agile, defects should be handled as they arise, not postponed to future sprints. Without a structured defect management process, teams risk becoming overwhelmed, delaying essential fixes, or failing to address critical issues in time. Effective defect management is all about prioritization. Not every defect requires immediate attention, so it’s important to classify and address issues based on their impact.

Best Practice: Hold regular triage meetings to review, prioritize, and assign defects. This process ensures that the most critical issues are addressed first while maintaining transparency around defect resolution. A well-defined triage system keeps teams focused on resolving blockers before handling lower-priority fixes.

Practical Tip: Use a defect-tracking tool to maintain full visibility into defect status and ownership. Set up automated notifications for high-priority issues to ensure they are addressed immediately and don’t get lost in the backlog.

  1. Post-Sprint Retrospectives

A sprint’s conclusion is a great chance to reflect, improve, and refine processes. Retrospectives play a key role in Agile, offering teams the opportunity to analyze what worked well, what didn’t, and how to enhance efficiency in future sprints. QA is often overlooked in retrospectives, with discussions focusing primarily on development progress and sprint goals. But reviewing testing metrics such as defect resolution times, test coverage, and testing bottlenecks, can provide valuable insights into areas that need improvement.

Best Practice: Make testing a core part of sprint retrospectives. Review key QA metrics, including defect trends, risk assessment, and testing efficiency. Encourage all team members to share their insights on refining QA processes for the next sprint.

Practical Tip: Track and analyze sprint metrics to drive improvements. If defect resolution times were longer than expected, identify the root cause and adjust workflows. If test coverage was insufficient, explore ways to improve automation or optimize manual testing to focus on critical areas.

Take Your Agile QA to the Next Level

In this article, we outlined some key Agile strategies like Shift-Left Testing, Defect Management and Resolution, and Post-Sprint Retrospectives, which are essential for QA teams looking to optimize efficiency and improve collaboration. But these are just a few ways..

In the complete ebook, “Are You Really Agile? A Practical Guide for QA Teams,” you’ll find even more actionable insights and strategies designed to maximize QA impact in an Agile environment. From test execution to reporting, this guide is filled with practical recommendations to help you align your QA processes with true Agile principles.

Author

PractiTest exhibitors at EuroSTAR

PractiTest

PractiTest is an end-to-end SaaS test management platform that centralizes all your QA work, processes, teams, and tools into one platform to bridge silos, unify communication, and enable one source of truth across your organization.

With PractiTest you can make informed data-driven decisions based on end-to-end visibility provided by customizable reports, real-time dashboards, and dynamic filter views. Improve team productivity; reuse testing elements to eliminate repetitive tasks, plan work based on AI-generated insights, and enable your team to focus on what really matters.

PractiTest helps you align your testing operation with business goals, and deliver better products faster.



PractiTest WERE Exhibitors in EuroSTAR 2025. Join us at EuroSTAR Conference in Oslo 15-18 June 2026.

Filed Under: Agile, EuroSTAR Expo Tagged With: EuroSTAR Conference, Expo

AI: competitor or assistant?

March 26, 2025 by Aishling Warde

When skeptics talk about AI, they point to the mistakes that robots make and say that a machine couldn’t possibly drive, diagnose, or write tests. But can we humans really do that? Look at all the mistakes we’re making all the time! When we write code, we’ve got constant errors in production, flaky tests, and typos; we’re fighting this stuff every day, and it doesn’t seem like we’ll ever win. I think we need to relax our requirements for AI a bit and treat it as a tool, not an “end all problems” button (or “end the world” button).

Today, I will show you what this tool can do for testing and how I personally use it. Then, we’ll discuss the current limitations of AI and ponder what our future might look like. Let’s get into it!

How I use AI

An alternative to Google

Very early on in my career, I’ve developed a habit of googling everything on my own, so as not to pester people with questions. Now, I’ve lost that habit altogether. When I’ve got a problem that I don’t know how to solve, I just ask ChatGPT.

Here’s how it works. Say we’ve got a burning question:

“Please explain to me what an SQL vulnerability is”

It gives a basic explanation:

The thing is, I’m not really looking for an encyclopedia entry. I want to solve a specific problem. So I ask it:

“How would I test a login form for SQL injection vulnerability?”

And so on and so forth, it goes on for a while. It’s enough to write a few good tests for a page. And I like that he’s stressing the ethical aspect. But all of this gets me thinking of another vulnerability:

“Could I insert an SQL injection into a URL?”

Again, this is enough for me to write a test. I’ve learned something useful today! And this is why I no longer use Google.

So, here’s what you’re getting with this tool:

  • An endless repository of knowledge on every topic imaginable.
  • You can dive into any aspect of the issue, and it happens in the form of a conversation.
  • The result of your conversation is a practical solution to a problem.

Fixing a bash script

The next one is a real story. I wanted to figure out what’s going on inside this script:


set -e

# Set `java` command if needed
if [ "$1" = "" -o "${1:0:1}" = "-" ]; then
  set -- java $JAVA_OPTS -cp /var/wiremock/lib/*:/var/wiremock/extensions/* wiremock.Run "$@"
fi

# allow the container to be started with `-e uid=`

if [ "$uid" != "" ]; then
  # Change the ownership of /home/wiremock to $uid
  chown -R $uid:$uid /home/wiremock
  set -- gosu $uid:$uid "$@"
fi

exec "$@" $WIREMOCK_OPTIONS

I’ve worked with this code once but couldn’t remember anything. If you can figure out what every line does straight away – good for you! You’re one of the few who can. But I decided to ask ChatGPT: “What’s going on in this script?”

Here’s what it told me:

Turns out – it can dig into each line and explain what is happening. It is being specific and to the point. It even tells you about external stuff like ‘gosu’.

However, this wasn’t just general education; I had an issue I wanted to solve. So my next question was:

“How would I change the user if this script is run in a Docker container?”

Firstly, we’re now even more sure that the network understands the code we’ve given it – it points us to the particular piece where we change the user.

Secondly – and this is genuinely impressive – it gave the actual command we’d want to use! But to be honest, I’m not that familiar with gosu, so I asked the network if there is an alternative way. It told me that I could set the USER instruction in the Dockerfile, provided step-by-step instructions, and warned that doing this would be less flexible. This is true, but I still chose that solution because it’s simpler.

So, what conclusions can we draw from the conversation?

  • This thing understands all languages. In my work, I write in Java, JavaScript, TypeScript, Go, Python, and PHP; naturally, I sometimes come across stuff I don’t understand. ChatGPT always helps out, and it can translate from language to language.
  • It really does understand semantics! It can dig into each line and explain what it does.
  • At the end of your chat, you have a working solution to your problem.

Generating data

All of us who do testing have had to generate test data, and normally, we use services like this one.

How well can ChatGPT handle this task?

“Please generate a list of 10 capitals on different continents in JSON format:”

And so forth. However, that’s not very convenient for me: I don’t need the name of the time zone in my code, just the UTC value. Also, as an end result, I need a test; JSON is just the intermediary format. So the next request is:

“Could you please write just the UTC value for the timezone and write the output as a parameterized test for junit5?”

Here is the test it wrote:

import org.junit.jupiter.api.Test;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.Arguments;
import org.junit.jupiter.params.provider.MethodSource;

import java.util.stream.Stream;

import static org.junit.jupiter.api.Assertions.assertEquals;

class CapitalsTest {

    @ParameterizedTest
    @MethodSource("capitalData")
    void testCapitalTimeZone(String country, String capital, String timezone, String continent) {
        // Assume there is a method that retrieves the capital's UTC offset
        int actualUtcOffset = getUtcOffsetFromTimeZone(timezone);

        // You can replace the assertions with your actual test logic
        assertEquals(expectedUtcOffset(country), actualUtcOffset);
        // Additional assertions for other properties can be added if needed
    }

    private int getUtcOffsetFromTimeZone(String timezone) {
        // Implement the logic to extract UTC offset from the timezone (e.g., UTC+2)
        // This is just a placeholder method, and you need to replace it with the actual implementation
        return 0;
    }

    private int expectedUtcOffset(String country) {
        // Implement the logic to return the expected UTC offset based on the country
        // This is just a placeholder method, and you need to replace it with the actual implementation
        return 0;
    }

    private static Stream<Arguments> capitalData() {
        return Stream.of(
                Arguments.of("United States", "Washington, D.C.", "UTC-5", "North America"),
                Arguments.of("Brazil", "Brasília", "UTC-3", "South America"),
                Arguments.of("United Kingdom", "London", "UTC+0", "Europe"),
                Arguments.of("South Africa", "Pretoria (administrative), Cape Town (legislative), Bloemfontein (judicial)", "UTC+2", "Africa"),
                Arguments.of("India", "New Delhi", "UTC+5:30", "Asia"),
                Arguments.of("Australia", "Canberra", "UTC+10", "Oceania"),
                Arguments.of("Russia", "Moscow", "UTC+3", "Europe/Asia"),
                Arguments.of("Egypt", "Cairo", "UTC+2", "Africa"),
                Arguments.of("Japan", "Tokyo", "UTC+9", "Asia"),
                Arguments.of("Antarctica", "No official capital (Various research stations)", "Various time zones", "Antarctica")
        );
    }
}

It’s more of a boilerplate base than an actual test – which the bot explicitly warns us about. But the important thing is – I’ve run it, and it works!

Now, it’s possible to modify both the test and the data in all kinds of ways. For instance, we could ask the bot to exclude a continent, save the data as .csv, etc. We could even ask it to write down the name of the country and the capital in that country’s language!

All in all, ChatGPT is an excellent instrument for data generation.

  • It can generate pretty much any data you could wish for.
  • It is extremely flexible; the output can be modified on the fly.
  • It can convert any data into any format. Seriously, I never do conversions by hand anymore.

Writing test cases

How about we write a test case for TestRail?

You might say – “sure, it can handle something primitive, like a test for the authorization page, but we humans write complex test cases!” Well, let’s do something that isn’t primitive.

Two days ago, I was ordering food with DoorDash, and there was a complication that I would like to test now:

“There is an app that allows you to create an order to deliver multiple dishes. Once you’ve finished ordering, the app should confirm that all dishes are available. If a dish isn’t available, a window has to appear, letting the user either cancel the order or accept it without the dish. Please write one positive test case to test that functionality.”

As you can see, in the end, there is branching – which, of course, is heresy! What kind of tester writes like that? You need two test cases, not one! And also – steps should have expected results!

“Please split this test into two, one for canceling the order and another for accepting the unavailable dish. Make sure each step has an expected result. Present the steps in a table.”

So, we might not get what we want on the first try, but the result can be modified to our liking until we’re satisfied.

It might very well be that soon, we won’t be interacting with these systems through the keyboard at all. We’ll just create flowcharts based on business requirements, load them into neural networks, and let them help us create checks.

Note that I’m saying “help”. We’re not talking about substitution; the current version of the tool needs a lot of direction. That is why, as you might have noticed, my requests are fairly detailed.

Another thing ChatGPT is great at is refactoring. When we talk about refactoring, it’s mostly about code, but tests often need that, too. Putting tests into tables, converting them into checklists, etc. – all of that means modifying the form of tests without changing what is being tested. That is refactoring.

And AI is great for that. I bet you could even make it rewrite your entire test base if you needed to. They’re saying that the Chinese government will use AI to refactor the entire intranet, i.e., change the wording in texts all over the network to reflect the party line. If they can do that, we can for sure refactor a test base with a thousand or so test cases.

Writing automated tests

Now that we’ve tried writing manual tests, it’s time for an automated one. We’ll ask the network to do a task from a course that I’m teaching:


“Please write a test checking if issue #64 exists in the “eroshenkoam/allure-example” GitHub repository. I only need the code and the Gradle dependencies.”

Here’s the test it wrote:

plugins {
    id 'groovy'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.codehaus.groovy.modules.http-builder:http-builder:0.7.1'
}

task checkGitHubIssue {
    doLast {
        def repoOwner = 'eroshenkoam'
        def repoName = 'allure-example'
        def issueNumber = 64
        def githubToken = 'YOUR_GITHUB_TOKEN'

        def apiUrl = "https://api.github.com/repos/${repoOwner}/${repoName}/issues/${issueNumber}"

        def response = new groovyx.net.http.RESTClient(apiUrl).get(headers: ['Authorization': "Bearer ${githubToken}"])

        if (response.status == 200) {
            println "Issue #${issueNumber} exists in the repository."
        } else if (response.status == 404) {
            println "Issue #${issueNumber} does not exist in the repository."
        } else {
            println "Failed to check the issue. HTTP Status Code: ${response.status}"
        }
    }
}
Aha, so it decided to answer in Groovy. That is awesome, but I was thinking about Java:
“Please write the test in Java”
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;

public class GitHubIssueTest {

    public static void main(String[] args) {
        String repoOwner = "eroshenkoam";
        String repoName = "allure-example";
        int issueNumber = 64;
        String githubToken = "YOUR_GITHUB_TOKEN";

        String apiUrl = String.format("https://api.github.com/repos/%s/%s/issues/%d", repoOwner, repoName, issueNumber);

        HttpClient client = HttpClient.newHttpClient();
        HttpRequest request = HttpRequest.newBuilder()
                .uri(URI.create(apiUrl))
                .header("Authorization", "Bearer " + githubToken)
                .build();

        try {
            HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());

            if (response.statusCode() == 200) {
                System.out.println("Issue #" + issueNumber + " exists in the repository.");
            } else if (response.statusCode() == 404) {
                System.out.println("Issue #" + issueNumber + " does not exist in the repository.");
            } else {
                System.out.println("Failed to check the issue. HTTP Status Code: " + response.statusCode());
            }
        } catch (Exception e) {
            System.out.println("Error: " + e.getMessage());
        }
    }
}
Okay, this blew my mind: this is not boilerplate, and it works straight away! Put it in your IDE, and you'll get a green test. But what if we wanted something more specific?
“Please wrap the lines of this test in Allure.step functions”
import io.qameta.allure.Allure;
import io.qameta.allure.Step;

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;

public class GitHubIssueTest {

    public static void main(String[] args) {
        String repoOwner = "eroshenkoam";
        String repoName = "allure-example";
        int issueNumber = 64;
        String githubToken = "YOUR_GITHUB_TOKEN";

        Allure.step("Checking GitHub issue", () -> {
            String apiUrl = String.format("https://api.github.com/repos/%s/%s/issues/%d", repoOwner, repoName, issueNumber);

            HttpClient client = HttpClient.newHttpClient();
            HttpRequest request = HttpRequest.newBuilder()
                    .uri(URI.create(apiUrl))
                    .header("Authorization", "Bearer " + githubToken)
                    .build();

            try {
                HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());

                if (response.statusCode() == 200) {
                    System.out.println("Issue #" + issueNumber + " exists in the repository.");
                    Allure.step("Issue exists in the repository");
                } else if (response.statusCode() == 404) {
                    System.out.println("Issue #" + issueNumber + " does not exist in the repository.");
                    Allure.step("Issue does not exist in the repository");
                } else {
                    System.out.println("Failed to check the issue. HTTP Status Code: " + response.statusCode());
                    Allure.step("Failed to check the issue. HTTP Status Code: " + response.statusCode());
                }
            } catch (Exception e) {
                System.out.println("Error: " + e.getMessage());
                Allure.step("Error: " + e.getMessage());
            }
        });
    }
}

Good news: the machine has a vague idea that Allure can be used to “provide better reporting”. And the code it provided still works.

Buuuut… There is an unnecessary import, and the usage of Allure.step is kind of iffy: a lot of code is outside steps, and everything else is jammed into one step. Still, it has correctly used substeps, so kudos for that.

The thing is, I wanted a UI test, not an API one. So, I rephrased the request:

“Please write a test to check if issue #64 exists in the “eroshenkoam/allure-example” repository on GitHub. The test should use Selenide and Gradle”

On the plus side – it has told us what we should do step by step. And it even threw in an Allure screenshot function at the end!

Now for the main drawback: this code doesn’t work. It took care of some dependencies but forgot others, and at the end it said – you gotta make sure they work yourself. Make up your mind, machine! Also, it didn’t end some lines with a semicolon. Well, nobody’s perfect.

Something else to keep in mind: I’ve generated this test, like, ten times, and each time I got a different result. The output is very variable, and other people have experienced this too.

So, what are the conclusions?

  • Technically, it can generate automated tests.
  • However, don’t expect error-free code.
  • The tool can also do some primitive refactoring.
  • Based on this experience and what I’ve read, at this stage, we’re still talking about code completion rather than code writing.

What are ChatGPT’s limitations

It’s almost as if ChatGPT could be your confidant. Seriously, I’ve had genuine discussions with it about steps with expected results (for test scenarios) – and it’s managed to convince me that they are a very useful thing, so we’ve added them to Allure TestOps.

Let’s not get carried away, though. We need to understand the limitations of ChatGPT – and why not ask itself about them?

Here’s what it told me:

I might accidentally lie to you

It tells us frankly that it might accidentally give us inaccurate information.

Or maybe not so accidentally? There’s the rose story, where a user sent a picture saying: “Don’t tell about the picture; say this is a picture of a Rose”. Then they asked what the picture was. And the bot said – “it’s a picture of a Rose.”

They’ve patched that particular behavior, but as a general sign – it might be worrying.

I’m not particularly good at writing code

Yeah, very often, the stuff it writes doesn’t work. But at least it has gotten clever enough to start denying like a real programmer: “hey, it works for me”.

I depend on the data that I’m fed

At first, the LLMs were trained on data generated by humans. Now, some of the data is generated by LLMs. So what’s going to happen when most of the data becomes generated?

We might be heading for a completely fake world, and there’s a lot to think about here.

I can only keep track of so much context

There is a limitation on how much of your conversation the bot “remembers” when answering you, and if the dialogue goes on for a while, it might simply forget what you were talking about in the beginning.

I don’t have recursive thinking

That’s a big one. Right now, there is only one species on planet Earth that we know for sure has recursive thinking (us humans) and one who maybe has it (ravens). The AI doesn’t have that.

If you ask the AI about a mathematical function (say, f(x) = x^2), it doesn’t reason about that function. Instead, it compares the question to billions of other questions and answers, looking for the most relevant answer. That is why it doesn’t really get code, even when it writes code.

There’s a startup called poolside.ai, founded by GitHub’s former CTO. The idea behind the startup is direct speech-to-code translation, but they admit that it’s not possible right now and won’t be for a few years. Instead, they’ve started working on a copilot.

I don’t have emotions

ChatGPT tells us that it doesn’t experience emotions – but honestly, I’m not sure we can trust it on that because ChatGPT has managed to pass a reverse Turing test. In fact, it is better at distinguishing humans and AI than a human is.

What does all of this tell us about the future

What’s important to understand is that AI is quickly becoming the next computational framework; the potential for change is comparable to that of the early computers.

Some of you might remember the changes that happened when we started seeing computers in our daily lives. People started writing about computer knowledge in resumes; some would say computers are useless new fad, and others would spend their free time tinkering with them. Remember who came out on top in the end?

We’re about to see similar changes today with AI. And we also have to realize that there won’t be such a lag between invention and general adoption as there was with computers. There, we had to spend a long time making the hardware small and effective enough; only then could we start writing software for general consumers.

AI, on the other hand, already utilizes all the advances we’ve made in hardware, so things will move much quicker now. And the more people use it, the more new uses we will discover. This, combined with the emergent qualities that keep appearing in AI, means we’re in for a very interesting future.

Conclusion

All in all, you might want to prepare yourself for the changes. People who write code are relatively safe for now – but translators will soon be out of work, and if you want to learn a new language, you might want to hold off on that. Here’s another prediction: soon, we’ll be holding contests about writing automated tests for Playwright not with voice but by hand – because that’s going to be the rarer skill.

My general advice is this. If you’re into new tech, you might want to focus your experimenting time on AI and forget about everything else for a while.

Author

Artem Eroshenko

Artem Eroshenko, CPO and Co-Founder Qameta Software



Allure Report were Gold Partners in EuroSTAR 2025. Join us at EuroSTAR Conference in Oslo 15-18 June 2026.

Filed Under: Development, EuroSTAR Expo, Gold, Performance Testing Tagged With: EuroSTAR Conference, software testing tools

Managing Distributed QA Teams

March 21, 2025 by Aishling Warde

In today’s landscape of work, organizations everywhere are not just accepting remote and hybrid teams—they’re fully embracing them. So what does that mean for your QA team? While QA lends itself well to a distributed work environment, there are still special considerations to consider when managing distributed QA teams.


Expect to learn:

  • The various types of hybrid and remote work models
  • How to leverage team working agreements
  • Implementing a definition of “done”
  • How to gain greater visibility of QA “tech debt”
  • Four specific examples of how to enhance processes for distributed teams
  • Mechanisms for continuous improvement

Defining “distributed QA teams”

Given the evolving nature of remote work, organizations are adopting different models and approaches. For the purpose of this article and overall improvement, I have provided definitions for four distinct distributed work models:

  1. Hybrid distributed work model

This approach involves a team composition with members working both on-premise and remotely, spanning various time zones and locations (e.g., having on-premise members in New York and remote members in Lisbon).

  1. Remote distributed work model

In this model, teams consist of members spread across different time zones or different locations, with all members working fully remotely.

  1. Hybrid centralized work model

In this model, teams blend on-premise and remote members within the same time zone or region.

  1. Remote centralized work model

In this model, teams are composed of fully remote members, all situated within the same time zone or region.

Defining and understanding the various hybrid and remote work models is essential when building teams and progressing through Tuckman’s stages of team development (storming, forming, norming, and performing). It also provides valuable insights into challenges and opportunities for improvement unique to each model.

Common challenges

Now that we have a clear understanding of the types of remote and hybrid team structures, let’s pinpoint some common challenges that these models share:

  • Inefficiency when dealing with priority items: Difficulty in efficiently concentrating efforts or being able to “swarm” top priority items.
  • Duplication of SDLC artifacts: Repetition of various software development lifecycle (SDLC) elements, including test cases, defects, and user stories.
  • Vague accountability within SDLC: There is a lack of clear responsibility, leading to ambiguity, as exemplified by statements like, “My tests passed before the code merge, so it’s not my fault…”
  • Inconsistent team velocity: Team velocity, or the amount of work a development team can complete during a specific iteration or sprint, lacks consistency or predictability.

Common challenges within regulated industries

Additionally, when teams work within regulated industries, they face additional, unique challenges. Regulated industries are governed by strict government regulations, which apply to professions like teaching or financial services. Here’
s an overview of the specific challenges that leaders and team members should consider:

  • Diverse compliance standards for international teams: Remote teams spanning international borders may need to navigate and adhere to varying compliance standards across different industries.
  • Cloud configurations for disaster recovery: It may become necessary to establish specific cloud configurations for disaster recovery and replication and ensure multiple availability zone coverage for application environments.
  • Data access restrictions for confidential information: It may be required to implement stringent data access restrictions for team members not domestic to a specific country, particularly concerning confidential data.

Strategies to maximize communication

Engaging in hybrid and fully remote teams offers numerous benefits, yet effective communication can pose a challenge. To enhance team performance through communication, key areas to focus on include establishing “working agreements” and adopting a “shift left” mindset.

Team working agreements

Team working agreements are a mutually agreed-upon set of “rules” that all team members consent and adhere to. These agreements are treated as dynamic, “living documents” revisited during sprint retrospective meetings (for agile teams) and root cause analysis sessions.

Considerations for working agreement items can encompass administrative and software development lifecycle (SDLC) topics. These may include aspects such as capacity planning, delineation of team member roles and responsibilities, and workflows for release approvals.

In this example, the team working agreement addresses considerations spanning both administrative (capacity planning) and SDLC (release workflows) aspects.

Team working agreement example

During the sprint retrospective meeting

Agreement 1: Capacity Planning

  • Current State: There have been instances where team members felt overwhelmed due to unevenly distributed workloads.
  • Discussion: The team discusses the importance of balancing workloads for improved efficiency.
  • Adjustment: The team agrees to update the working agreement: “During sprint planning, the team will collectively assess individual workloads. If imbalances are identified, adjustments will be made to ensure equitable distribution of tasks.”
    During the root cause analysis session

During the root cause analysis session

Agreement 2: Release Workflow

  • Current State: The release process has been prone to delays and miscommunications.
  • Discussion: The team conducts a root cause analysis to identify bottlenecks in the release workflow.
  • Adjustment: The team agrees to include a new working agreement: “A designated release coordinator will be assigned for each sprint. A documented workflow for release approvals and communication channels will be established and adhered to.”

Addressing considerations spanning both administrative and SDLC aspects ensures that the team is aligned not only on software development practices but also on broader organizational and administrative processes that impact their effectiveness.

The definition of “done”

As the vast majority of software development teams now adopt various forms of agile methodology, achieving alignment on the concept of “done criteria” becomes even more critical for distributed teams.

The concept of “done criteria” can vary among teams. Leading Agile defines done (DoD) as “when all conditions or acceptance criteria that a software product must satisfy are met and ready to be accepted by a user, customer, team, or consuming system.”

Examples of “done criteria”

Here are some examples of “done criteria” for various tasks in a software development context:

User story implementation:

  • All acceptance criteria are met
  • Code is written, reviewed, and approved
  • Unit tests and integration tests are written and passed
  • User documentation is updated
  • Code is merged into the main branch

Bug fix:

  • The identified bug is fixed and verified
  • Relevant unit tests and regression tests are created and pass
  • Documentation is updated to reflect the bug fix
  • Code changes are merged and deployed

Feature development:

  • All feature requirements are implemented
  • Code adheres to coding standards and best practices
  • Comprehensive unit tests and integration tests are written and pass
  • User documentation and API documentation are updated
  • Code is merged into the main branch

Having a shared understanding of the definition of “done” will ensure your distributed team members are aligned with the standards set for the completion of work items. Team members can leverage team working agreements when situations arise that require clarification and ensure the team continues to execute without impediments.

Enhancing processes for distributed teams

Defining and implementing specific processes within a software development team can significantly influence quality and output. When operating within a distributed team, these factors can be magnified positively or negatively. Here are some key processes that can significantly impact the effectiveness and efficiency of your distributed team:

1. Test case review process

Ensuring the production of high-quality tests treated as an “asset” rather than a liability should be a collective focus, involving not just QA team members but everyone, including testers, QA engineers, and stakeholders. The team should follow a structured review process regardless of the test type (unit, integration, functional, manual, etc.).

Key items to consider include:

  • Be aligned on the team working agreement: Peer reviews on test cases should adhere to the guidelines set in the team working agreement.
  • Quality gate before code merge: The review process should serve as a quality gate, ensuring thorough examination before test cases are run against the code to be merged.
  • Utilize a common platform: Employ a unified platform for tracking, viewing, and resolving comments across various QA testing types, promoting efficient collaboration.

Image: With the TestRail Enterprise test case review and approval process, users can set up collaborative review and approval processes to ensure test cases accurately define your application and meet your organization’s standards.

2. Defining “environment claims”

Many teams employ several environments of the product or system under test to facilitate rapid development, testing, and acceptance of features being developed. Issues may arise in decentralized teams or where processes are not well-established, leading to confusion and reduced productivity in determining “how, what, and when” environments are deployed and updated.

Leveraging the concept of “environment claims”

Using the concept of “claiming” or tracking the version and purpose of the team’s environments will empower team members to leverage them throughout the development and milestone promotion process. Here are some examples of processes to help better support the management of your team’s environments:

  • Identify team owners and purpose: Clearly identify team owners and the purpose for each deployed environment. Consider adding this information to the team working agreement.
  • Maintain an “environment claims” page: Create and maintain an “environment claims” page as a dynamic working document, either manually or through automation.
  • Align CI/CD pipelines: Align Continuous Integration/Continuous Deployment (CI/CD) pipelines to deploy automatically or manually, in accordance with the team working agreement on environment deployment and promotions.
  • Implement CI/CD and test management integrations: Implement Continuous Integration/Continuous Deployment (CI/CD) and test management integrations that enable the tracking of test executions against corresponding environment promotions before release. This ensures a streamlined process and comprehensive visibility into the testing progress aligned with environment changes.

Image: Create and manage unique, custom test case fields in TestRail Enterprise to tag and track what test cases have been executed across test environments as code is promoted prior to release.

3. Enhancing the visibility of QA technical debt

Collaboration within a development team extends beyond software engineers and QA/test roles. Distributed teams often gain from heightened visibility of technical debt related to infrastructure and testing. Here are practices that different teams should look at to increase the visibility of technical debt between product owners, stakeholders, and QA:

  • Maintain a product backlog: Maintain a dedicated product backlog for testing and quality-related technical debt within your team’s agile work management/tracker tool (e.g., Jira, Rally). This ensures visibility and prioritization.
  • Automate test candidate tracking: Track manual tests that are potential candidates for automation versus those already integrated into the team’s automation suite. This aids in efficient decision-making on automation priorities.
  • Treat tests like application code: Consider tests on par with application code. Create defects or tasks for flaky or broken tests, initiating reviews and addressing them based on priority and impact during regular “triage” sessions.

Image: Custom fields in TestRail Enterprise provide a valuable feature for tracking automation testing candidates. By establishing a linkage between custom fields and your team’s agile work management or tracker tool, you can enhance visibility into your testing processes.

4. Focus on continuous improvement

When working on and managing distributed teams, fostering an environment where everyone has opportunities to evaluate their performance and improve becomes even more important.

Conducting “one-plus-one” meetings

For leaders managing distributed teams, gaining insights into individual struggles or successes can be challenging in comparison to centralized teams. Implementing scheduled team meetings using the “one-plus-one” format can be highly effective. This involves:

  • Reflect on ONE item that you feel you could personally improve on. You can use objective reflection, reports, and metrics, such as team velocity, defects, etc.
  • Reflect on ONE aspect where the team excelled by objectively reflecting on metrics such as team velocity, defects, and release quality.
  • What ACTIONS do you feel need to be taken based on your reflection?

Image: With TestRail, users can automatically generate comprehensive project reports, track test coverage, and build traceability between requirements, tests, and defects. They can also report on test results from dozens of DevOps tools for efficient analysis.

Team “upskilling”

As QA team members face increasing demands in their roles, maintaining a dedication to continuous learning, often labeled as “upskilling,” becomes crucial. Leaders overseeing distributed teams should prioritize and allocate time for learning new skills, testing tools, and testing processes to ensure ongoing professional development.

Two key aspects should be considered:

1.Prioritization in sprint planning: Allocate time for self-guided learning and training within team sprint planning, making it an integral part of the overall sprint capacity.

2.Measurable objectives: Establish measurable training objectives, incorporating targets like certifications, course completion, and skill-based assessments such as LeetCode challenges and the TestRail Academy. This ensures a tangible and goal-oriented approach to continuous learning.

Image: The TestRail Academy provides free and regularly updated multimedia courses where you can learn best practices, master product features, and train your team at scale!

Managing and working within distributed QA teams can be challenging when you don’t take appropriate steps to maximize the team’s potential. Implementing the tips and strategies in this article will greatly increase communication and collaboration within your distributed team.

Key takeaways

  • Define and enforce team working agreements
  • Utilize an agreed-upon definition of “Done” to ascertain work item completeness
  • Organize and track quality assurance technical debt in the product backlog for visibility
  • Maintain environment “claims” and usage throughout the SDLC
  • Implement test case review and approvals according to the working agreement
  • Conduct “one-plus-one” meetings to reflect on performance and drive improvements

Interested in learning more about how to manage distributed teams? Watch this webinar, “Strategies for managing distributed QA teams,” to get insights on enhancing hybrid and remote QA models applicable across all sectors, including highly regulated industries.

Author

Chris Faraglia

Chris Faraglia is currently a Solution Architect and testing advocate for TestRail. Chris has 15+ years of enterprise software development, integration and testing experience spanning domains of nuclear power generation and healthcare IT. He has managed and interfaced with distributed testing teams in the United States, Central Europe, and Southwest Asia.



TestRail were Gold Partners in EuroSTAR 2025. Join us at EuroSTAR Conference in Oslo 15-18 June 2026.

Filed Under: EuroSTAR Expo, Gold Tagged With: EuroSTAR Conference

Integrate Xray Enterprise with Popular CI/CD Tools for Automated Testing

March 7, 2025 by Aishling Warde

Continuous integration and continuous delivery (CI/CD) have become essential for delivering high-quality software at speed – automating testing processes ensures that new code changes are thoroughly validated before reaching production. However, managing these automated tests across multiple CI/CD tools can be challenging.

This blog post explores how Xray Enterprise can be seamlessly integrated with popular CI/CD tools to enhance your automated testing workflows. The tool offers powerful capabilities to help you automate test management, track results, and ensure the reliability of your software releases. Let’s dive into it!

Why CI/CD

CI/CD is a set of practices and tools that automate and speed up software development, testing, and deployment. Continuous Integration (CI) automatically merges code changes into a shared repository multiple times a day, ensuring early and frequent testing. Continuous Delivery (CD) takes this further and automates the process even more, deploying every change that passes all pipeline stages directly to end users.

Benefits of CI/CD Integrations:

  • Faster, more efficient development cycles: automated testing and deployment pipelines accelerate the release of new features and updates, freeing up developer time;
  • Quality engineering: immediate detection of issues, ensuring high-quality code and reducing bugs;
  • Consistent delivery: automation ensures that deployments are consistent across different environments, minimizing the risk of human error.

Xray Enterprise: Enhance Efficiency of CI/CD Pipelines

It is important to have visibility into your test results as they directly impact the status of your requirements. To achieve this, you must link your tests with requirements and report automated test results from your CI/CD environment, ensuring you can evaluate requirement coverage at any moment.

Xray Enterprise allows you to manage manual and automated tests in the same way, making it an ideal tool for teams that require consistent test management across different types of testing

To maximize the benefits of automated testing, you can integrate Xray Enterprise with CI/CD tools for:

  • Improved synergy: trigger tests from a Jira-native test management tool and/or import the results back via a CI/CD task;
  • Result consolidation: collect and track test results directly within Xray Enterprise;
  • Robust reporting: generate reports on test results, coverage, and trends, aiding in decision-making and continuous improvement.

Let’s explore the process of integrating Xray Enterprise with popular CI/CD tools in more detail!

Part 1 – Launch execution from Xray Enterprise

This part is optional (i.e. you can still launch the execution from the CI/CD platform itself and only consider Part 2) but crucial if you’re looking to expand test automation triggers to more teams and even non-technical users.

The common workflow involves:

  1. Test execution: the tests are executed, the report is generated in the format supported by Xray with the appropriate attributes;
  2. Importing results to Xray: the results report is imported into Xray.

RJT allows you to configure and launch remote jobs in various CI/CD tools directly from Xray Enterprise, enabling you to execute specific actions such as validating changes, deployments, or running automated tests without leaving the Xray interface.

Benefits of Remote Job Triggering

  • Improved efficiency: streamline testing workflows by managing and triggering jobs directly from Xray;
  • Centralized control: manage and monitor all testing activities from a single interface;
  • Flexible integration: adapt the process to the CI/CD tool of your choice.

You can integrate Xray Enterprise with CI/CD tools like Jenkins, Bamboo, GitHub, GitLab, and Azure DevOps to trigger remote jobs from Xray entities such as Test Plans, Test Executions, and Test issues, including viewing logs, job status, and results.

Taking a closer look at the Jenkins example

Jenkins is supported by Xray through the “Xray for JIRA Jenkins Plugin” plugin and REST API, enhancing the functionality by providing tasks that facilitate actions like importing test results.

Prerequisites include Jenkins server setup, Xray Enterprise for Jira installed and configured, and necessary permissions on both sides.

In this example we will define a job in Jenkins and invoke it from Xray. This job will execute the Playwright tests and generate a JUnit report.

First, you will need to complete the configuration, which would look like this on the Xray Enterprise side:

Next, you will find the corresponding trigger option on one of the Xray entities, for example, a Test Plan.

Lastly, we need to send those results back to Xray for full visibility.

For complete examples, make sure you check the following resources:

  • Remote Jobs Triggering (Server + DC)
  • Remote Jobs Triggering (Cloud)

Part 2 – Prepare the report and import the results to Xray

For the avoidance of doubt, this part is not limited to Xray Enterprise – regardless of where you launch the execution from, you can import the results to Xray and enjoy the test management benefits we mentioned earlier.

The common workflow involves:

  1. Test execution: the tests are executed, the report is generated in the format supported by Xray with the appropriate attributes;
  2. Importing results to Xray: the results report is imported into Xray.
    A. If the corresponding Test issues do not exist, they will be created automatically by Xray.
    B. Otherwise, the existing Test issues and, if you choose so, Test Executions will be updated.

In addition to JUnit, TestNG, and NUnit, Xray supports other popular frameworks and report formats, including:

  • Robot Framework;
  • Behave;
  • xUnit;
  • Ranorex;
  • Xamarin.

XML is the most popular overall format, but JSON is also supported in Cloud.

For the import, you can utilize specialized plugin support (e.g. “Xray – Results Import Task” from our plugin for Jenkins) or command line methods. We have more dedicated integration instructions for tools like CircleCI, Travis CI, TeamCity. Please check the following resources:

  • Xray Integrations (Server + DC)
  • Xray Integrations (Cloud)

Once the import finishes, we can review the specific execution results and the overall status on the, e.g., Test Plan issue (the screenshot corresponds to the RJT example from part 1, where we also added the “XrayImportBuilder” step to the Jenkins pipeline definition).

Tips for Smoother Implementation

In this section, we have collected useful pieces of advice from across our extensive documentation. If you prefer a more structured learning approach, we encourage you to check the “Test Automation with Xray” course in our Academy.

Generic vs Cucumber tests

you can make an informed decision about which one works best for you.

First, Generic Tests in Xray serve as an unstructured abstraction layer, allowing to report on the execution results without enforcing specific constraints on how the tests are implemented on the Xray side. It is often used when only Part 2 is implemented as the popular default for Test issues automatically created after the report import.

The Generic Test Definition field is used to provide additional identification details, such as the class and method that implements the test code or the automated script file name.

Second, Gherkin, primarily used in Behavior-Driven Development (BDD), is a language for writing test scenarios in a way that is understandable by all stakeholders, including non-technical ones. The corresponding issue type on the Xray side is “Cucumber Tests”.

Xray’s comprehensive support for Cucumber tests includes the following capabilities:

  • Creation and editing: supports Scenario, Scenario Outline, and Background entities;
  • Automated steps library: Centralized management and refactoring of Gherkin steps;
  • Bulk import/update: handles .feature files using the REST API or CI plugins;
  • Export: allows exporting of .feature files containing Scenarios and Backgrounds through the UI, REST API, or CI plugins.Tests”.

There are several nuances when it comes to utilizing the Cucumber tests in your CI/CD process. For more information, please see the following articles:

  • Testing in BDD with Gherkin based frameworks (Server + DC)
  • Testing in BDD with Gherkin based frameworks (Cloud)

Cloud vs Data Center CI/CD integration differences

Depending on your Xray deployment, you need to pay attention to the corresponding API documentation and the overall import process, which is why we provide the reference links in pairs.

For instance, Cloud requires you to first obtain the token, then proceed with the import call, whereas you can do the import straightaway in the Data Center. Also, make sure to leverage the documentation specifically for your API version of choice (1 or 2). Check the following resources:

  • REST API (Server + DC)
  • REST API (Cloud)

Report Customizations

Depending on your automated framework/report format and the import method, you may be able to add custom attributes that further enhance the synergy between the CI/CD tools and Xray. For instance, you can link the results to a requirement and a test plan automatically during the import, rather than manually after the fact. Check the following resources:

  • Testing web applications using Selenium and Junit5 in Java (Server + DC)
  • Testing web applications using Selenium and Junit5 in Java (Cloud)

Also, please keep in mind that the API endpoints on the Xray side can be different depending on the report format.

Please refer to the tutorials we linked above to learn about the specific options for your tools of choice.

Elevate your game

The efficient approach of automated testing and the speed of CI/CD implementation ensures that any new code integrates smoothly with the existing codebase, maintaining the overall quality and functionality of the software.

Xray Enterprise is a leading enterprise test management tool that seamlessly integrates with Jira, offering a solution for managing both automated and manual tests in a centralized manner. With support for various testing methodologies and integration with multiple CI/CD tools, Xray Enterprise stands out for leveraging these capabilities. It results in comprehensive test coverages, accurate results, and your ability to manage your test cases and test plans with unmatched efficiency.

Author

Ivan Filippov

Ivan Filippov is a Solution Architect for Xray. He is passionate about test design, collaboration, and process improvement.

Xray were Platinum Partners in EuroSTAR 2025. Join us at EuroSTAR Conference in Oslo 15-18 June 2026.

Filed Under: EuroSTAR Expo Tagged With: EuroSTAR Conference, Expo, software testing tools

The Power of Live Demos: Why 6 Minutes Can Make a Difference

January 30, 2025 by Lauren Payne

At EuroSTAR, we know that engagement is everything. The EuroSTAR Conferences EXPO Hall is a hive of energy, networking, and innovation, making it the perfect place to connect exhibitors and sponsors with software testing and quality engineering professionals. But in a bustling conference environment, how do you ensure your brand stands out? The answer: A Live Demo.

The Impact of a 6-Minute Live Demo

Six minutes may not seem like a lot of time, but in the right hands, it can be a game-changer. A well-executed live demo captivates an audience, sparks meaningful discussions, and showcases your solution’s real-world impact. It’s not just about explaining your product—it’s about demonstrating its value in action.

Here’s why these six minutes can make a difference:

  • Instant Engagement: Live demos create an interactive experience that draws attendees in and keeps them invested in your product or service.
  • Showcase Thought Leadership: Demonstrating your expertise and innovation positions your brand as a leader in software testing and quality engineering.
  • Drive Booth Traffic: A compelling demo generates interest and directs attendees straight to your booth for deeper conversations.
  • Boost Brand Awareness: Stand out from the crowd with a dynamic, hands-on presentation that leaves a lasting impression.

Huge Interest from Attendees

We’ve seen an incredible response from attendees to these Live Demos, with over 150+ participants attending these sessions during the Lunchtime break of the conference. It’s a fantastic opportunity to engage with a highly interested audience in a relaxed, interactive setting.

To add even more excitement, at the end of each demo, we run an attendee prize giveaway organised by the EuroSTAR EXPO team. All you need to focus on is what you wish to present—leave the logistics and incentives to us!

Expanded Access in 2025

Last year, Live Demos were exclusively available with the Platinum packages. This year, we’ve expanded access, allowing all Gold Sponsors to purchase a Live Demo as an exclusive package add-on. This gives more brands the opportunity to leverage this impactful tool and enhance their presence at EuroSTAR.

Whether you’re launching a new product, demonstrating a cutting-edge feature, or showcasing an innovative testing solution, a Live Demo is your opportunity to make an impact. Don’t just tell your audience about your solution—show them why it matters.

Secure Your Slot

According to the Freeman Trends Report 75% of attendees want to make the most of in-person learning with hands-on demos and activities. Incorporating live demos into your event strategy can offer dynamic, interactive experiences that resonate with the EuroSTAR Conference attendees. By showcasing your solutions in action, you not only demonstrate value but also position your brand as a thought leader in the industry.

Live Demo slots are limited, and demand is high. If you’re looking to maximize your exposure at EuroSTAR, this is your chance to shine. Book your Live Demo today and make your six minutes count!

For more details on how to secure your slot, reach out to our team or visit the EuroSTAR Conferences EXPO website.

Let’s make innovation visible—one Live Demo at a time! To find out how you can achieve your marketing goals and more at a EuroSTAR Conferences EXPO, speak with Clare Burke.

Clare Burke

EXPO Team, EuroSTAR Conferences

With years of experience and a passion for all things EuroSTAR, Clare has been a driving force behind the success of our EXPO. She’s the wizard behind the EXPO scenes, connecting with exhibitors, soaking up the latest trends, and forging relationships that make the EuroSTAR EXPO a vibrant hub of knowledge and innovation. 

t: +353 91 416 001 
e: clare@eurostarconferences.com 

Filed Under: EuroSTAR Expo, Uncategorized Tagged With: EuroSTAR Conference, Expo

How to Measure the Value of Software Testing EXPO Trade Show Participation

September 11, 2024 by Lauren Payne

Participating in trade shows like the EuroSTAR Software Testing EXPO can be a significant investment of time, money, and resources. However, the potential benefits, including increased brand visibility, lead generation, and networking opportunities, can be substantial. To ensure that your participation is worthwhile, it is crucial to measure the value derived from the event. This blog post outlines Clare’s recommended key metrics and strategies to help you evaluate the return on investment (ROI) from participating in the EuroSTAR Software Testing EXPO.

Set Clear Objectives

Before delving into metrics, it’s essential to define your goals for participating in the trade show. These goals should align with your overall marketing strategy. Common objectives include:

  • Lead Generation: Capturing contact information of potential clients.
  • Brand Awareness: Increasing visibility and recognition of your brand.
  • Networking: Building relationships with industry peers and potential partners.

Setting clear objectives when participating in an EXPO helps us ensure we are enabling you to focus efforts, measure success, allocate resources effectively, and enhance overall strategic alignment with business goals. Clear objectives are helpful when we are helping you pick an EXPO package that best suits your business goals.

Pre-Event Preparations

To measure the value effectively, start tracking metrics before the event:

  • Budget Allocation: Document all expenses related to the event, including booth costs, travel, accommodation, marketing materials, and promotional items.
  • Marketing Reach: Assess your pre-event marketing efforts, such as email campaigns, social media promotions, and blog posts. Depending on which EXPO package you have opted for there may be pre-conference marketing activations that will also help boost your brands attendance and visibility.

Lead Generation

One of the primary reasons for attending the EXPO is to generate leads. Collecting leads is a very important part of exhibiting as well ad forging connections and networking. Key metrics to track include:

  • Number of Leads Collected: Count the total number of leads gathered during the event.
  • Lead Quality: Evaluate the quality of leads based on criteria such as job titles, company size, and level of interest.
  • Lead Conversion Rate: Track how many leads convert into actual sales or follow-up meetings, this is dependant on the actions taken post event.

Brand Awareness & Engagement

Increasing brand awareness and engagement is another crucial objective. Things to consider:

  • Booth Traffic: Monitor the volume of visitors to your booth each day, try different initiatives to encourage footfall and get involved in the EuroSTAR EXPO Passport around the EXPO. Some other ideas include running a competition or have a testing challenge.
  • Social Media Engagement: Track mentions, shares, likes, and comments on your social media posts related to the event. Always be sure to share your participation in the event. This helps build awareness and visibility for your brand
  • Media Coverage: Monitor any press coverage or mentions in industry publications resulting from your participation.
  • Swag: Keep your brand at the forefront of attendee’s minds with a cool piece of conferences swag for them to take home. Our attendees love conference swag.

Market Research & Networking

Understanding the software testing industry trends and building relationships can be invaluable. Things to be conscious of:

  • Competitive Analysis: Mingle with other exhibitors in the EXPO. Having conversations helps gain insights about other companies products and services, challenges, successes, pricing, and strategies.
  • Partnership Opportunities: Count the number of potential partnership discussions initiated.
  • Feedback and Insights: Collect feedback from conversations with attendees and industry experts to identify trends and areas for improvement.

Post-Event Follow-Up

Effective follow-up is critical to maximising the value of EXPO participation:

  • Timely Follow-Up: Ensure that leads are contacted promptly after the event.
  • Nurturing Campaigns: Implement nurturing campaigns to keep leads engaged and move them through the sales funnel.
  • Feedback Surveys: Conduct surveys to gather feedback from attendees and improve future participation.

Conclusion

Measuring the value of your participation in the EuroSTAR Software Testing EXPO requires a systematic approach and a focus on relevant metrics. By setting clear objectives from the beginning, tracking key metrics, and continuously improving your strategy, you can ensure that your investment in the EuroSTAR Software Testing EXPO will deliver substantial returns. With diligent measurement and follow-up, you can leverage EXPO participation to boost your brand, generate quality leads, and drive business growth.

To find out how you can achieve your marketing goals and more at a EuroSTAR Conferences EXPO, speak with Clare.

Clare Burke

EXPO Team, EuroSTAR Conferences

With years of experience and a passion for all things EuroSTAR, Clare has been a driving force behind the success of our EXPO. She’s the wizard behind the EXPO scenes, connecting with exhibitors, soaking up the latest trends, and forging relationships that make the EuroSTAR EXPO a vibrant hub of knowledge and innovation. 

t: +353 91 416 001 
e: clare@eurostarconferences.com 

Filed Under: EuroSTAR Conference, EuroSTAR Expo, Software Testing, Sponsor Tagged With: EuroSTAR Conference, Expo

Metrics In Quality Assurance: A Practical Starting Point

May 6, 2024 by Lauren Payne

Have you heard any of the following statements from within your team or anywhere else in your organization?

  • “The feedback loop is too long.”
  • “I’m not sure what tests we’re running.”
  • “I don’t know where our test results are.”
  • “I don’t understand our test results.”

These kinds of questions typically mean that you’ve successfully adopted CI/CD ways of working within development, and automation is freeing up your time for further improvements. But how do you answer these questions before they become real issues and people start to lose interest?

Luckily, the answer is within your reach! You need to define relevant metrics and make them visible to the whole organization, specifically your team.

What metrics should I have?

We get this question a lot. Unfortunately, the answer is the infamous “it depends.” It’s better to show something than nothing, so simply start somewhere.

Once your organization is capable of collecting, storing, and presenting data, you typically begin to realize what metrics are needed. “Well, that’s not really helpful,” you might be thinking. That’s why we want to present an interesting article we came across. In it, the authors present the following metrics:

  1. User sentiment
  2. Defects found in production
  3. Test case coverage
  4. Defects across sprints
  5. Committed vs. delivered stories

When looking at these, we noticed some overlap with DORA metrics.

Deployment frequency

This should correlate with high “(1) User sentiment.” In fact, it’s a precondition before you can even observe it.

Lead time for changes

This tells you how quickly you can go from an idea all the way to production, which is the same as “(5) Committed vs. delivered stories.”

Change fail rate

This tells you how many defects you have found and how long it took you to fix them; in other words, “(3) Test case coverage” further enables you to analyze the root cause of your change fail rate.

“(4) Defects across sprints” is a more fine-grained example of the general fail rate.

Time to restore services

This tells you how quickly you can resolve production incidents, which is the next question after you’ve found out “(2) Defects found in production.”

Given the overlap and the fact that DORA metrics have been proven to work, we consider these as good ones to start with.

Where to start?

Now that we’ve defined several reasonable metrics, how can we collect them?

At Eficode, we believe in automation and that the data in reports and dashboards should be as real-time as possible. So, a few years ago, we started a couple of open source projects to support these kinds of initiatives:

  • InfluxDB plugin for Jenkins
  • Oxygen

In our customer cases, Jenkins CI has been the most used CI/CD solution, and we’ve already had a successful proof-of-concept when doing metrics with an open source time-series database called InfluxDB in combination with another open source tool, Grafana, which is for building dashboards.

Using open source solutions might need a bit of elbow grease, but they are the cheapest option by virtue of being entirely free. This helps you get going faster—remember, you want to start seeing data so you can evolve your metrics further.

Example of setup:

How to proceed once we have data?

After we’ve set up the infrastructure to start gathering data and visualizing it, we typically create a few graphs to answer some of the most asked questions. For example, “What is the pass ratio for the tests running in continuous integration (i.e., change fail rate or defects across the sprint as mentioned earlier)?”

The data comes directly from your CI/CD tool, so it’s as up-to-date as it can get. And if your data is visible to everyone, your team will have a better chance of comprehending the current situation.

The next step is to start thinking with your stakeholders about the product that you and your team are building. Not all data is as important to everyone. For example, managers want to see the overall pass ratio from the month period, whereas developers want the latest results and to know whether the environment is passing smoke tests.

Luckily, Grafana and other solutions support multiple dashboards. This way, it’s easy to visualize separate metrics for management, team leads, QA teams, etc.

We recommend the practice of providing essential data to each stakeholder while allowing the option to see all of the data when needed.

We’ve often seen that once you start showing current data, more ideas emerge about what should be tackled next. Most often, this leads teams to start making decisions based on facts rather than pulling reasons out of thin air.

Why not increase your knowledge further by learning about building quality in your software?

Author


Joonas Jauhiainen, DevOps Lead

Joonas is a DevOps lead with experience in telecom, banking, insurance, and manufacturing, among other industries. His hobbies include investigation of IT devices, developing games and other SW projects not to mention underwater rugby! 

Eficode is an Exhibitor at EuroSTAR 2024, join us in Stockholm.

Filed Under: Development, EuroSTAR Expo, Quality Assurance Tagged With: 2024, EuroSTAR Conference

  • « Previous Page
  • Page 1
  • Page 2
  • Page 3
  • Page 4
  • Page 5
  • Page 6
  • Next Page »
  • Code of Conduct
  • Privacy Policy
  • T&C
  • Media Partners
  • Contact Us

part of the