Solving Test Environment Challenges Through Our Partnership with CQE

That sense of involvement and shared success is exactly what defines the partnership between Apwide and the people who stand beside us, our partners.  Dom Blair, Practice Director for Environment and IT Service Management at CQE, is one of those partners. 

Last week, our founder, David, and key account manager Gabriel had a great conversation with Dom, and we're glad to share some of the insights that can be useful for anyone working with environment management.

Getting to Know CQE

CQE was founded almost 11 years ago by a team of consultants who had previously worked together at companies like Accenture, IBM, and Deloitte. Containing a wealth of experience, they support clients across all areas of software testing, from process transformation to tooling and automation. More recently, they’ve also been exploring how to apply AI and test data strategies to strengthen their services.

With Dom joining the team, there was an opportunity to expand their offering by including environment management since many of CQE's clients were already using tools like Xray and Jira.

Getting to Know Golive

How did you first hear about our product?

Dom Blair spent a lot of time looking for tooling that could support environment management in a real and practical way. Most tools either disappeared after a while, didn’t quite solve the actual pain points or would be viewed as cost-prohibitive to several clients. 

"Going back over the 10 or 12 years, one of the hardest things about being someone who works in the consulting space and specializes in environment management is the abstract lack of good tooling. And one day, Golive appeared in one of my search results. From that point on, it just became the go-to recommendation. I was already using Jira for demand and requirements management. It made sense to look at something that lived in the same ecosystem. I found Golive, got on a call with David, had a demo, and I immediately had a client who could benefit from it.”

That was six or seven years ago. Since then, unless a client already has tooling in place, Golive has been his default recommendation for greenfield implementations.

Once Golive enters the picture, things change quickly. For many, it's the first time visibility has become a reality. Suddenly, teams know who’s using what, when, and why. They're not waking up to broken integrations or two weeks of testing gone because someone deployed overnight. They're not losing money just because someone forgot to book an environment.

Golive is embedded in Jira, and that familiarity is what helps people overcome resistance. No new logins. No new URLs. No jumping between tools. It just works inside Jira, the tool they're already using every day. "The quickest way to reduce the impact of change, especially if it's a new piece of software... is to not look like a new piece of software."

Test Environment Management Challenges

What are the most common challenges that those customers are struggling with now?

When we asked Dom about the most common challenges in environment management today, he made it clear that the issues tend to fall into a limited set of patterns. Some organizations have no environment management in place at all, while others have all the right tools but lack a proper operating model around them. And that’s where things tend to break down.

For Dom, the focus is on building a complete service around those tools and defining processes, roles, and ways of interacting with the system, not just implementing tools. As he puts it, “A product is only as good as the process, and the people around it. You can have the best tooling in the world, but if you don’t have the right way of interacting and working with it, then everything you put in place is going to fail.”

What’s surprising is how little progress some teams have made over the years. Dom started working in environment management back in 2010 when environments were still managed in spreadsheets. Even now, he continues to see companies operating without change control, version tracking, or any real visibility into their environments.

Often, no one knows exactly what their test estate looks like because responsibility is spread thin, application teams manage certain components, product owners manage a few others, and testing tends to focus on performance environments. But no one sees the full picture.

How does the lack of proper tooling impact their performance?

The result? Delays, miscommunication, and a ripple effect can derail entire test cycles. Dom shared an example that makes the consequences crystal clear:

”If we look at that particularly difficult client situation, we have several test environment landscapes. It was probably a medium-sized estate. There were maybe 850 to 900 individual test environments, the work instances of applications, and about four people managing different bits of them. Two were on a big project and were sitting in testing, trying to do their best.

But no one had an overall view of the estate. Components were being swapped to be connected up to different areas so the end-to-end testing could happen. Releases were going in without any communication because it was assumed that no one else was using that same environment. So that's fine: I can just put some new code in there overnight, and as a result, that could invalidate two weeks' worth of testing.

The worst scenario is a large data load that's going on, and that could take an environment out of the loop for maybe 3 or 4 days, especially if we've got overnight batch runs that are going to disseminate data to other systems. And all of a sudden, an entire landscape is simply not available.

You've got an environment itself that might be key to testing going on, but it's no longer available for several days. You've got testers who now have completely derailed test plans. They're going to have to go and look at doing something else. This may be, key defects that are required to be tested within a particular release, and it's no longer available, all of which comes down to the same thing.”

”The biggest impact is always time and money.”

Challenges while Implementing Golive

What challenges do you often see in an implementation?

”I was asked this question by a customer at the end of a demo a couple of weeks back. And it's 100% the resistance to change by the people within an organization. Not wanting to use a new tool, not wanting to have an extra step in that process.

And that is the close-coupled nature of Golive being a Jira plugin. It's the familiarity. Because the quickest way to reduce the impact of change, especially if it's a new piece of software, is to not look like a new piece of software.”

Dom has been implementing change for a long time, too long, as he joked, but experience has taught him that while every client might look different on the surface, the problems they face are often remarkably similar. That’s why he leans on a standardized approach. “Even though your customers are going to be very different, what you're putting in place, the problems you're fixing, you can take a very standardized approach. The minute you start tailoring it too much, you're building bespoke solutions, which makes it hard to go back and maintain.”

Instead of reinventing the wheel for each new client, he works with three core models that cover most cases. There's always an initial assessment, sometimes in-depth, sometimes just a light touch, depending on where the customer stands. From there, the implementation begins with a plugin setup, predefined workflows, and clear processes that form the backbone of a reliable environment management service.

The goal isn’t to build something from scratch. It’s to offer consistency. As Dom puts it, most companies don’t have a formal environment management function at all, so what they need is a framework they can trust. “It’s only the touchpoints that you amend for each customer. What they’re asking for is a reliable service, a repeatable set of processes and steps.” That repeatability is key to maintaining quality and avoiding complexity.

The process usually starts with a small proof of concept, a simple project, ideally one that won’t cause too many surprises. “We rattle a few ideas out, they get familiar with what we’re doing, and we sign it off”. Once that’s done, implementation moves into production. Environments are loaded, and they might onboard a first project, preferably not a “problem child.”

But sometimes that’s exactly what they start with. Dom recalled a client where they deliberately picked the most challenging project, one that had serious environment issues. “We put it in the tooling, and magically, in two weeks, it hadn’t fixed the project, but their environments were in good shape.” That’s the power of structure, results can come quickly when teams have the right visibility.

The rollout is supported by thorough training, user documentation, and process alignment, especially important for SAP-heavy teams. And after 25 years of putting similar systems in place, it’s a method that continues to work. “I tend to find that it’s worked for me for pretty much all the things I’ve been implementing over the last 25 years or so.”

“That’s more or less how long I’ve been alive,” Gabriel replied.

“Don’t say that,” Dom laughed.

“As I was saying it, I immediately regretted it. But honestly, it just makes me respect your experience even more.”

Understanding the Implementation Scope

Would you say there’s a typical timeline for an implementation? And are there specific factors, like the tools already in the toolchain, that tend to make it faster, slower, easier, or more difficult?

Dom explained that setting up workflows and automation is usually straightforward. “I can pretty much nail down the amount of work I need to do, down to a number of hours or days. But the timeline often changes depending on the complexity of the environment.”

When the estate includes a mix of on-prem, cloud, and interconnected systems, especially when applications are built from multiple microservices, more time is needed to decide how to map that data into Golive. “You’ve got to put a lot of thought into how you map the applications and the environment information when you load it,” he said.

One of the main blockers is that many teams don’t know what their full test estate looks like. After the initial assessment, Dom often asks clients to gather information manually. “What environments do you have, what are they used for, what are their designations? If there’s no CMDB, we also need basic details like physical locations. And all of that can add up to a third of the implementation window.”

By contrast, when the client has a structured landscape, the setup is much faster. “I’ve worked with teams that just book by landscape. The data’s in good shape, and that alone can reduce the timeline significantly.”

Integrations are usually not a problem. Thanks to the way Golive is designed, most connections are simple to scope and quick to implement. Features like environment cloning also help, especially for teams working with templates or build-and-burn models.

A typical implementation takes around three months, which includes an initial assessment and planning, but that can vary depending on the size of the estate, integration scope, and internal alignment. As Dom noted, “Even after everything’s in place, you still need to help the team sell it internally, through demos, training, and day-to-day support.”

Golive Benefits

What are the most noticeable improvements teams experience after implementing Golive , and how soon do they typically see those results?

Once Golive is in place, teams don’t need to change their routine to see the impact. Test managers simply open their Jira dashboards and start the day with more clarity on what environments are available and how they’re performing. As Dom put it, “They are immediately starting every single day with a lot more confidence in testing“. Without doing anything differently, besides adding a new gadget to their dashboard.

“Your test managers are going to come in the morning, look at a Jira dashboard, and see what environments they've got. And if we've got monitoring tools and stuff set up, they'll see if anything's down or running slowly.

Without having to do anything different, apart from adding an extra gadget to their daily dashboard. People who are doing deployments may grumble a little bit because we may have introduced a little bit of control around releasing code into test environments.

Not everything can be ten releases a day. Not everything should be ten releases a day. There's a controversial statement. But it's always about that sudden awareness without effort, which I think is the biggest win.“

The value becomes even more evident when new projects start and environment requests begin. Instead of chasing emails or waiting days for provisioning, teams fill in a basic form and follow the entire process inside Jira, step by step. There’s no guessing, no chasing, and no manual reporting, “they’ve got a full, traceable, step-by-step process… and they can do real-time self-serve reporting on it,” all without leaving the tool they already use.

It also prevents the usual last-minute surprises: broken integrations, removed environments, or unexpected changes pushed into shared spaces overnight. Those incidents don’t just disrupt testing, they erode trust. Sometimes, Dom said, the most meaningful change doesn’t come from complex automation or deep integrations. It comes from something simpler: a clearer picture. “The fancy stuff is great, but it’s all unseen. It’s the simple, clean presentation of information that usually makes the biggest difference.”

Most Represented Industries

Would you agree generally with the statement that maybe actually, industry doesn't matter as much as just the scale?

When asked about the industries that benefit the most from Golive, Dom Blair resists narrowing it down to a specific segment. From his experience, it’s less about the vertical and more about the scale of digital operations, especially in organizations with frequent releases and strong client-facing platforms.

Retail, for instance, often tops the list in terms of release volume. As he explains, “Every retail customer I’ve ever worked with is going to hate me for saying this, but the amount of importance and criticality that’s placed on a website, when really, the website is just the shop window, is huge. But there are constant changes throughout the day: maybe there’s a new marketing campaign, maybe a sale needs to go live, maybe it gets triggered unexpectedly. And you’ve got to have done all the testing to support the influx of users, especially during something like Black Friday.”

That kind of dynamic, high-speed environment calls for reliable coordination and visibility, which is where  Golive shines. But he also sees strong adoption in industries like financial services, where agility is present on the surface but paired with deep caution on the backend. Updates to banking apps and customer-facing websites happen frequently and with confidence. On the other hand, systems like payment engines, which handle billions of dollars daily, are treated with extreme care.

Dom recalls working on a dollar clearing system for a UK bank,  an implementation that spanned nine months. “Every single change after that was handled with extreme care and due diligence; you can’t just push ten updates a day into money-critical systems like that,” he says.

During the conversation, Gabriel brings up something he’s observed on the Apwide side: a surprisingly large number of gaming companies using Golive. Dom finds that interesting, not just because it hadn’t occurred to him as a pattern, but also because he’s recently been exploring that world himself. While game development involves constant testing, he’s noticed some weak points in practices around version control and environment management.

“It seems like some of the practices around version control and branching aren’t great. Environment management for testing, rollbacks, traceability, it all seems a bit hit or miss. Definitely something I want to explore.”

Still, Dom doesn’t believe Golive’s value is confined to any one industry. What matters most is complexity, the number of releases, the environments in play, and how much coordination is required to keep things moving. From his time at Cognizant to his current role at CQE, he’s worked across financial services, insurance, healthcare, life sciences, and more, and he’s never seen a need to specialize by sector. “I’ve never categorized my practice based on industry. Everyone needs to test things. The moment industry starts to matter is when you need deep domain knowledge, when the tools, workflows, and applications are unique to that space. But from a release and environment management standpoint? The challenges are universal.”

Post-implementation Insights

And what happens after Golive implementation? 

Once the implementation is complete and the first real Golive takes place, there’s still work to be done to make sure the investment continues to deliver value. When asked about how to maximize return after the initial rollout, Dom shared that this post-implementation phase is something he takes seriously, even admitting he tends to “make a bit of a nuisance” of himself by staying actively involved with the client. “One of the things I always try and develop with any customer is what their roadmap is going to be post-Golive implementation.”

This becomes especially relevant with larger clients who’ve often spent the past few years navigating complex migration plans. Many of them haven’t fully stabilized their environments yet, and over time, they start shifting toward a “build-and-burn” model, which means further internal migrations on the Golive side.

At the same time, new features from Apwide Golive are released regularly. Dom keeps an eye on those updates and forwards release notes to his contacts, pointing out what’s newly available and how it might align with their plans. “Here’s something we looked at on your roadmap, they’ve just brought it out as functionality in the plugin. I think that could bring that forward from month eight to maybe month three.”

These kinds of nudges often lead to follow-up conversations. But for Dom, it’s about ensuring clients don’t miss out on improvements that could benefit them right away. “If you put a product in place and you don’t revisit the changes to that product, and maybe the benefits of using it in a slightly different way, then that team and their usage of that product, in my mind, will start stagnating.”

He sees it as part of his responsibility to keep those teams informed, not because he’s looking for more billable hours, but because he cares about the long-term outcome. “I think it comes out of professional pride as well. You’re only as good as your last job. And what you don’t want is the people from your last job saying, ‘Well, he put this product in and disappeared.”

Apwide Partnership

How would you describe your partnership experience with the Golive team?

”It was brilliant until he called me old.” Dom

As a result, there have been several conversations sparked by new pieces of functionality. Dom mentioned how he’d been bringing up the idea of spider maps for quite some time, and eventually, that suggestion turned into a real feature. He laughed about how he’s still giving David a hard time about the application custom field, but there’s a deeper point beneath the jokes.

“Normally, when you talk to a product supplier and say, ‘This would be a nice-to-have,’ you get pointed to a form, fill it out, and maybe a year later you’ll hear it’s been added to a backlog, if you hear back at all,” he said. “I’ve never experienced that here.”

Instead, he described having genuine conversations about ideas that, while sometimes specific to his way of working, felt truly heard. “We’ll wrap up a call, I’ll go make a coffee, come back to my desk, and there’s an email waiting, letting me know the suggestion’s already been added to the backlog. It’s things like that.”

For him, that’s what inclusion looks like. It’s the sense that you're not just using a tool, you’re shaping it. “You feel like you’re contributing to a product you really believe in and recommend with confidence. But you also feel personally involved. And I think that’s immensely rare in the software world today.”