One Platform, Many Teams: How The Aspen Group Empowered QA, Dev, and SRE Teams

The Aspen Group unified QA, Dev, and SRE testing with Testkube, replacing manual, siloed workflows with a scalable, automated, Kubernetes-native quality engineering process.

Summary

The Aspen Group adopted Testkube to unify fragmented testing across QA, Dev, and SRE teams, transforming manual, siloed workflows into a scalable, Kubernetes-native process for automated quality engineering.

• Company: The Aspen Group (TAG), a fast-scaling healthcare services platform
• Challenge: With manual QA, no standard framework, curl-based triggers, and siloed ownership, testing needed to catch up with infrastructure maturity.
• Solution: Adopted Testkube to unify testing across QA, Dev, and SRE with a Kubernetes-native orchestration platform
• Why Testkube:
  • Framework-agnostic (supports Playwright, K6, curl, and more)
  • Easy to use (via UI or CLI) for teams with mixed skill levels
  • Built for Kubernetes-first workflows with native triggers

• Impact:
  • Testing became a shared, scalable process, not a person-dependent task
  • QA, Dev, and SRE now collaborate through a single test platform
  • Faster incident response through on-demand test execution
  • Ongoing shift from manual QA to versioned, automated quality engineering
  • CI/CD pipeline integration and event-based testing in progress

Building modern infrastructure needs modern testing

The Aspen Group (TAG) is more than a healthcare services company. It is a technology-driven platform that supports a growing network of dental, veterinary, and urgent care brands across the U.S. While many of its peers are just beginning to modernize their IT foundations, TAG has already adopted scalable, cloud-native infrastructure. Today, over 85 percent of its workloads run in Kubernetes, powering nearly 90 microservices that serve providers and patients nationwide.

But as TAG matured its platform, one part of the stack needed to catch up: Testing and test Automation.

When Joel Vasallo joined TAG as Director of Platform Engineering, he and his teams modernized the delivery and infrastructure stack. However, the testing processes hadn't kept pace. “We moved from a set of monolithic VM hosting over 900 and some odd APIs to now roughly 80 to 150 microservices across all the brands,” Joel said. Most workflows were still manual. Teams used a patchwork of curl commands and isolated scripts to trigger tests. There was no unified framework, no centralized visibility, and no easy way to collaborate across QA, Dev, and SRE.

“There was no formal testing framework, ” Joel explained. “One team might be doing manual QA, another writing integration tests with their own tools. Everyone had their own way of doing things. It was totally decentralized. ”

‍

That decentralization was workable, until it wasn’t.

The turning point: A Saturday outage and a Testkube PoC

The breaking point came during a P1 outage on a Saturday. TAG’s dedicated QA engineer was out of reach, and other team members weren’t available. A critical release was blocked until the SRE team remembered a Testkube proof of concept that had recently gone live.

“We had a test job in Testkube that mimicked what QA normally ran manually, ” Joel recalled. “The SRE team pulled it up, executed it, and suddenly we had a signal. ” The tests weren’t comprehensive, but they were enough to give the CTO confidence to ship a fix. “That would’ve been impossible before, ” Joel said. “That moment proved that testing didn’t have to be tied to a person. It could be tied to a process. And that process could scale. ”

The solution: Kubernetes-native orchestration for every team

Joel had first discovered Testkube at KubeCon. He was drawn in by its Kubernetes-native architecture but stayed for its flexibility.

“Triggering tests as Kubernetes jobs meant I could integrate them into our workflows—Argo, Spinnaker, whatever, ” he said. “It just worked. ” But more importantly, Testkube didn’t lock TAG into a specific testing approach. Teams could bring their own tools, such as Playwright, K6, curl, or internal scripts, and run them all through one orchestration layer.

“One team might use Playwright. Another might use K6. Someone else might just want to write a curl test. Testkube doesn’t care, it just runs it all. ”

‍

This tool-agnostic approach was key for TAG, where not everyone is a Kubernetes expert, and not every team has deep automation experience. “You can write a test with curl, ” Joel said. “That’s the entry point. Then, as folks grow, they can build richer suites. The platform grows with them. ”

Even the user interface played a key role. “Most of us live in the CLI, but that’s not true for everyone. Testkube gives you a visual dashboard, historical test data, and even recordings of Playwright runs. That accessibility matters. ”

The results: Cross-team collaboration, process resilience

With Testkube, testing at TAG evolved from siloed, person-dependent efforts into a shared, scalable process. The platform team owns deployment. QA creates and curates test libraries. Developers contribute tests directly. And SREs use the same jobs to validate fixes post-incident. This highlights how the engineering teams have grown and come together to modernize testing at TAG. “It’s a celebration of progress. ” - Joel.

“It doesn’t matter whether a test came from QA or Dev. Once it’s in the platform, it’s just part of the suite. Everyone can run it. Everyone can see the results.”

‍

This unified foundation has also helped the organization shift from manual QA to a more mature quality engineering practice. Tests are now version-controlled, stored in Git, and treated as production-ready artifacts. Collaboration is growing. Silos are shrinking.

“We’re helping teams understand that tests should be tracked, versioned, and deployed, just like any other piece of code. That’s how you grow from QA to QE. ”

‍

What’s next: Full CI/CD automation and event-based testing

TAG is now working to eliminate manual triggers entirely and build full test automation into their CI/CD pipelines. Joel put it simply: “How do I figure out, how do I add the CI/CD components to getting things out there and deployed?”

The QA team, he noted, is ready for it. “Click ops is not going to scale, ” he said. Teams are now defining tests as CRDs (Custom Resource Definition in K8s), versioning them in source control, and preparing for automatic execution on deployment events.

“There’s an API to deploy and YAML you can define, ” Joel added. “We’re helping QA understand that tests should be treated like deployments. You version them. You source control them. That’s the graduation from QA to quality engineering. ”

There are still items on his wishlist, including improvements to SSO handling and more out-of-the-box GitLab or Argo templates. But the foundation is strong. The value of Testkube isn’t in what it replaces, it’s in what it enables.

“I’m not selling Testkube as a QA tool, ” Joel said. “I’m selling it as a testing platform for everyone. It’s the glue. ”

‍

At a glance

• Company: The Aspen Group (TAG)
• Industry: Healthcare, platform services
• Stack: Python (FastAPI), .NET Core, TypeScript (Next.js/Angular), GraphQL
• Infrastructure: ~90 microservices, 85%+ Kubernetes-native
• Testing tools: Playwright, K6, curl, custom scripts
• Use cases:
  • On-demand testing during outages
  • Cross-team test orchestration
  • CI/CD test automation (in progress)
  • Unified dashboards and test artifact visibility
• Results:
  • Faster response to incidents
  • Reduced QA bottlenecks
  • Developer-owned testing
  • Shift from QA to quality engineering
  • Shared, scalable test infrastructure

Conclusion: A platform that scales with people, not just code

For The Aspen Group, adopting Testkube wasn’t just about automating tests. It was about enabling teams. By introducing a platform that works for developers, QA engineers, and SREs alike, TAG was able to shift testing from a bottleneck to a shared responsibility. It made outages less risky, releases more confident, and quality a company-wide priority rather than a niche specialty.

Testkube helped TAG close the gap between infrastructure and process maturity. It allowed the organization to move faster without compromising stability.

As TAG continues to scale its services and teams, Testkube provides the flexibility to evolve alongside them. Whether it’s integrating with new pipelines, onboarding new testing frameworks, or empowering non-technical users to own parts of the test lifecycle, Testkube ensures that quality is never an afterthought.

“Testkube didn’t just modernize our testing, ” Joel said. “It gave us a foundation to grow on, technically, culturally, and operationally. ”

‍

For fast-moving teams balancing scale, complexity, and collaboration, that foundation makes all the difference.