How ThinkSys Helped CRIO Achieve Faster, Parallel QA Testing in Every Release Cycle

For software companies serving clinical research teams, speed and reliability matter at every stage. When testing slows down, the impact reaches beyond the engineering team. Releases become harder to plan, developers wait longer for feedback, and QA teams spend more time preparing systems than testing the product.

In this case study, we will explore how CRIO introduced a dynamic QA automation environment for its SiteApp services. We will look at the approach used to automate infrastructure setup, database creation, application deployment, testing, and cleanup. We will also examine how the new workflow supported parallel testing, faster feedback, and more consistent QA environments.

Meet CRIO

CRIO provides clinical research software for research sites, sponsors, and contract research organizations. Its platform supports the key activities involved in running and monitoring clinical trials.

For a software company serving clinical research teams, application quality and reliability are essential. Development teams must test every change carefully without slowing planned releases. When testing environments are difficult to access or prepare, developers wait longer for feedback, QA teams spend more time on setup, and release planning becomes less predictable.

But they were facing a lot of issues. 

The Problems

• Limited access to QA environments: CRIO’s teams relied on a limited number of shared QA environments. When all environments were in use, other teams had to wait before they could begin testing.
• Lengthy manual environment preparation: Preparing a QA environment manually could take several hours. The time also depended on whether a shared environment was available when the team needed it.
• Multiple manual setup steps: The setup required teams to deploy SiteApp services, configure and seed the test database, and confirm that every part of the environment was ready.
• No support for parallel testing: Because teams shared a small pool of environments, multiple feature branches or teams could not test at the same time, which limited overall testing capacity.
• Delayed feedback for developers: Developers received feedback later because testing could not begin immediately. Issues were discovered further into the development cycle, increasing rework and reducing confidence before release.

We Offered Targeted Solutions

After reviewing CRIO’s QA process, we proposed a fully automated approach that would address each bottleneck while making testing faster, more consistent, and easier to scale.

• Create isolated QA environments on demand: We proposed provisioning a separate QA environment for every test run, removing dependence on shared systems and allowing teams to test changes without waiting for availability.
• Automate database creation and test data setup: We recommended automating Cloud SQL database creation and seeding so each environment would start with consistent test data, reducing setup effort and avoiding configuration differences.
• Standardize SiteApp deployments: We suggested deploying SiteApp services through GitHub Actions, Helm, and Argo CD to create a repeatable release process and reduce errors caused by manual deployment steps.
• Support parallel test execution: We proposed assigning a unique Kubernetes namespace to every execution, keeping environments isolated and enabling two or three teams or feature branches to test in parallel.
• Manage temporary resources automatically: We recommended automated retention and cleanup rules to remove temporary databases and namespaces after validation, control resource use, and prevent unused infrastructure from remaining active.

Results After Implementation

After implementing the automated QA environment, CRIO saw clear improvements in testing speed, team productivity, environment consistency, and resource management.

• Reduced manual work: Environment provisioning, database preparation, service deployment, testing, and cleanup ran automatically, reducing manual effort and allowing QA teams to focus more on validation.
• Parallel testing became possible: The solution supported two to three isolated QA environments at the same time, helping multiple teams or feature branches test changes without waiting for shared resources.
• Developers received faster feedback: Automated Playwright testing started after deployment, giving developers feedback earlier and helping teams identify issues before changes reached shared QA or production.
• Testing became more consistent: Every test run followed the same provisioning, database, deployment, and testing process, creating repeatable environments and reducing differences caused by manual configuration or setup errors.
• Resource management improved: Automated cleanup removed temporary databases and namespaces after the retention period, limiting leftover resources, supporting better infrastructure use, and creating a scalable base for future testing needs.

Implementation Approach

Step 1: Build the Automated Workflow

We first designed a GitHub Actions workflow that started when code was merged into the release branch. The workflow assigned a unique identifier to every execution and passed it across database, namespace, deployment, and testing tasks. This naming strategy prevented parallel runs from overwriting resources. We also added clear job dependencies so infrastructure was created in the correct order and failures stopped later steps from using incomplete resources.

Step 2: Create and Seed an Isolated Database

Next, we automated the creation of a dedicated Cloud SQL database for each test run and loaded it with seeded test data. Unique database names prevented parallel environments from sharing or changing the same data. We considered creation failures, incomplete seeding, and connection delays. The workflow checked each stage before continuing, ensuring SiteApp services received a ready, consistent database instead of starting against a partially prepared system.

Step 3: Deploy SiteApp Services in a Unique Namespace

After the database was ready, we generated a unique Kubernetes namespace and deployed the SiteApp services through Helm and Argo CD. The namespace isolated each execution, allowing two or three environments to run without service, configuration, or networking conflicts. We kept deployment values consistent while supplying run-specific names and database settings. Readiness checks prevented tests from starting before pods became healthy and producing false failures.

Step 4: Run Tests and Publish Results

Once the services passed readiness checks, the workflow launched the Playwright QA automation tests and collected the results. Tests ran against the isolated environment created for that execution, reducing interference from other teams or feature branches. We published the test output so developers could review failures without searching through deployment logs. Test failures did not immediately destroy the environment, giving teams time to inspect services, logs, and data.

Step 5: Retain and Clean Up Temporary Resources

Finally, we implemented retention and cleanup workflows for temporary databases and Kubernetes namespaces. Each environment remained available for 24 hours to support additional validation, while database cleanup followed the configured retention period, with seven days as the default. Cleanup had to remain reliable because failed or cancelled workflows could leave resources behind. Unique identifiers and age-based checks targeted only temporary resources, reducing the risk of deleting permanent infrastructure.

Conclusion

This case study showed how CRIO moved from limited shared QA environments to a faster, automated testing process. ThinkSys helped design and implement a workflow that handled infrastructure setup, database creation, SiteApp deployment, Playwright testing, and cleanup with minimal manual effort. Many software companies face similar delays when teams depend on shared environments and manual deployments. ThinkSys can help remove these bottlenecks with scalable QA automation built around each business’s tools and needs. Contact ThinkSys to create a more reliable and efficient testing process.

Facing similar challenges to CRIO?

Book a call