Centralizing Testing: How We Built Toast

Before Toast, testing at BTPN was fragmented across teams. Each squad used different frameworks, different reporting tools, and different CI configurations. There was no central visibility, no shared standards, and no easy way to onboard a new team to testing.

Toast changed that.

The Fragmentation Problem

Our testing landscape was a mess:

• Frontend teams used Jest and Cypress
• Backend teams preferred JUnit and Postman
• Performance testing was done ad-hoc with JMeter
• Some teams were experimenting with k6 and Selenium
• Reporting was scattered across Jenkins logs, JUnit XML files, and Slack messages

The result: no one knew the full picture of quality across the organization. A critical service could have 40% test coverage, and no one would know until it broke in production.

The Vision

We wanted a single platform where any team could:

1. Pick their testing framework (or use our recommended defaults)
2. Write tests as they normally would
3. Push to Git — that’s it

The platform would handle the rest: environment provisioning, test execution, result aggregation, and reporting.

And if a test failed, engineers shouldn’t need to dig through logs — the platform should tell them what went wrong and suggest fixes.

Architecture

React Dashboard
      ↓
API Gateway (Node.js)
      ↓
Test Orchestration Engine
      ↓
Containerized Test Runners
      ↓
Unified Reporting Database (PostgreSQL)

Test Runners. Each testing framework gets its own containerized runner. When a test job is triggered, the orchestrator spins up the appropriate runner container, mounts the test code, executes the suite, and collects results.

This container-based approach means we can support new frameworks without changing the core platform. Want to add Playwright support? Build a Playwright runner container and register it with the orchestrator.

AI Support Bot. One of Toast’s most successful features is the support bot. It’s trained on our testing documentation, common error patterns, and test configurations. Engineers can ask natural language questions like “why is my Cypress test flaky on CI?” and get contextual answers.

The bot handles 80% of testing support questions without human intervention. This alone saves the platform team 15+ hours per week.

What We Learned

Adoption requires zero friction. The most important design decision: engineers shouldn’t need to change how they write tests. Toast integrates with existing test files and CI configurations. The platform invisibly wraps around existing workflows.

Reporting is the product. Engineers don’t care about the test runner — they care about the results. We invested heavily in the reporting dashboard. Every test failure should answer three questions: What failed? Why did it fail? How do I fix it?

Standardization without rigidity. We provide recommended configurations that work for 80% of teams. But every team can override any setting. The platform suggests; the team decides.

Results

After 12 months:

• 6 frameworks supported (Jest, Cypress, JMeter, k6, Selenium, Appium)
• Unified quality visibility across the entire organization

Toast started as an internal tool. It’s now a core part of how BTPN ships software.