Customer storyHow Sunfox scaled QA for its Spandan ECG app — across real hardware, a shared device fleet, and a two-person team
A QA system that knows what the app should surface for each reading, queues its runs, and triggers from Jira. Before Quash, two engineers walked through the same suites by hand — on whichever phone was free, with the ECG unit connected each time.
Automated runs across first three months
469
Test suites built by two testers
25 suites · 242 cases
Regressions caught before release
5
QA hours freed per week
35 hrs
Execution trigger
Jira-triggered
Sunfox is a Dehradun-based medical technology company whose Spandan portable ECG devices are used across 15+ countries and 1,800+ pin codes in India. The Android app pairs with the device, drives a 12-lead recording, and produces a report. The Spandan app doesn't stand alone — it reads the ECG device plugged into the phone, interprets the signal, and surfaces one of a specific set of responses depending on what the reading shows.
Every test that mattered required a human staring at a screen
The Spandan app is only half the product. The other half is the ECG device plugged into the phone. The app reads the data coming from the device, interprets it, and surfaces one of a set of specific outcomes — a normal-reading confirmation, a specific result card, a prompt to retake the recording. Which one appears depends on what the reading actually shows.
Testing that meant looking at every screen, every time. The team was two engineers, testing entirely by hand. Every release ran through the same suites in sequence, on whichever phone was free, with the ECG unit connected each time.
The failures that hurt most weren't the kind a checklist could catch. The wrong result card surfacing for a given reading. A card that rendered with the right content but a shifted layout. A waveform on the report page with the wrong scaling. A test that said “record ECG, verify report” would pass a scenario where the report was produced but wrong. The only way to spot the difference was two people looking at every screen, every release.
The workspace was shared with the rest of engineering. Phones moved between desks and a wired automation setup wasn't going to work — nobody wanted specific phones tied to specific machines, and no one had time to keep re-configuring the rig.
The team's release workflow lived on Jira. Tickets moved through states as engineers worked: Pending to test, Failed to test, Ready for release. But there was no bridge between what a ticket said and what actually got tested. A ticket entered Pending to test and then sat, waiting for someone to pick it up, find a device, pair it, and run the scenario by hand.
One flow for the hardware, the app and the expected result
Quash's setup at Sunfox is a small QA platform built for the constraints. Phones connect wirelessly. Tests queue on a paired device without re-pairing. The agent knows what the app is supposed to do given a reading. The vision model checks whether it did. Jira is the trigger.
25 suites · 242 test cases · 469 runs
From manual walkthroughs to a fully queued, Jira-triggered device fleet — four changes that made it work:
An agent that knows what should surface
The agent has been given knowledge of what the app is supposed to do for what data — built from Sunfox's own reference test cases and the app's decision logic. When a test runs a known reference reading, the agent already knows which result should appear. The vision model confirms: right card, right position in the flow, right layout.
A queue that keeps the device working
Quash queues suites and cases against a device once it's paired. The device stays connected. The next run starts when the previous one finishes. The team can start a run at end of day and find results ready in the morning — without a hand on the setup between every run.
Wireless device configuration for a shared workspace
Quash connects to the fleet wirelessly — any phone in the office can be pulled into the pool by pairing it once, and it stays available until someone takes it out. No wired rig, no machine-specific config, no re-pairing when a phone moves desks.
Jira integration — the board triggers the run
Quash's integration listens for state transitions on the team's Jira board. When a ticket moves to Pending to test or Failed to test, the associated run queues on Quash automatically. No human moves it. By the time the engineer checks, the test is running or done.
Every failed run includes the screen at the point of failure, which card or frame the failure showed up on, and whether the failure was a result-card mismatch or a render issue. The team can see exactly what went wrong without re-running the scenario.
Before Quash
After Quash
“The failures that matter for us are the ones a checklist wouldn't catch — a card that shouldn't have shown up for that reading, a report that renders but shifts baseline. What we needed was a tool that could reason about what should happen next, and then actually check whether it did. The queue and the Jira trigger meant we weren't picking up devices between every test.”
The two testers get to test again
Before Quash, most of the two-person team's day was mechanical: pair a device, step through a scenario, look at the screen, write it up, move to the next. Three months in, that part runs itself. The team's time now goes into building new scenarios, reviewing the edge cases the AI flagged, and testing the parts of the product without coverage yet.
In the first three months, the suite caught 5 regressions before release — including two waveform rendering bugs and one case where the wrong result card was surfacing for a specific reading. A checklist wouldn't have flagged the last one. All three would have shipped otherwise.
35 hours a week between the two testers — most of a week per release going into the mechanical parts of testing — now runs itself. That capacity has moved to exploratory work and to new scenarios that don't have coverage yet.
