How a build actually moves through Pulse.
Six stages, one continuous line, no manual handoff between any of them. Below is what happens at each one — a generic example, and what changes versus doing it by hand.
Whatever already exists is enough to start.
A URL, an APK upload, an FRS document, or just screenshots. Pulse ingests what your team already has — there's no separate "write a test plan first" step before generation can begin.
- No prerequisite documentation — a build or a set of screenshots is a valid starting point
- FRS documents (PDF / .docx) parsed and grounded automatically
- Zero setup gate — submission moves straight into generation
Say your team just shipped a "forgot password" flow. There's no formal spec — just three Figma screenshots and a Slack thread. That's enough. Drop the screenshots in, and generation starts from what's actually there.
Someone spends a day or two writing a formal test plan from a Figma file and a Slack thread before a single case exists.
Screenshots go in. Generation starts inside a minute — no test plan authored by hand first.
Feature → sub-feature → typed test case, streamed live.
Every case is classified Positive, Negative, or Edge at generation time, and carries a traceable source reference back to the exact material it came from. Real runnable code from day one — no separate "automation later" step.
- Multi-modal — screenshots alone are enough, no text required
- Playwright for web, WebdriverIO/Appium for Android
- Coverage bot answers "do we have a case for X?" grounded only in real cases
The forgot-password flow becomes: Forgot Password → Reset via email link, then three typed cases — including an edge case for a reset link that's expired, which is easy to forget when writing tests from memory.
A QA lead hand-writes twenty test cases from the spec, guessing at edge cases from memory and past incidents.
The hierarchy generates in minutes, streamed live, with edge cases like an expired reset link already covered.
Manual when you need control. Automated when you need speed.
Manual rounds get one-click Pass / Fail / Blocked with an expandable panel for notes and evidence. Automated cases dispatch to a Pulse Agent — a single standalone binary — with live results and live screenshots streamed back per test.
- Filter by status, case type, epic, or free-text search
- Real-world blockers handled — a waitForOtp helper polls for codes via Twilio or Mac Messages
- Quick Launch — open any URL on an agent machine for an instant eyeball check
Round 1 of the reset-password suite runs against the Android build via the Pulse Agent — cases that don't need a human execute unattended with evidence attached, while the tester runs the trickier manual cases (the ones needing a real inbox) on the dashboard.
Manual regression day: a tester works through a spreadsheet, screenshotting failures by hand into a doc.
Automated cases run unattended with evidence attached automatically; manual cases stay one click per result.
Unregistered-email path now returns a 500 instead of the expected generic "if this email exists" message — likely the email-service refactor merged this morning.
Every failure classified before anyone opens the suite.
Real bug, flaky, or environment — each failure is classified, linked to the exact case it breaks, and shipped with a probable cause and a confidence score, not left as an unexplained red row.
- Classification: real bug, flaky, environment, or bad test data
- Probable cause, contributing factors, and a suggested fix
- Grounded in the actual failing result — its stack trace and screenshot
TC-02 fails on this run. Before anyone opens the suite, Pulse has already flagged it: 91% confidence, "real bug," with a note that the failure started right after this morning's deploy touched the email service.
A failure sits as a red cell in a spreadsheet until someone has time to dig into why it broke.
The failure ships with a probable cause and confidence score already attached — triage starts already narrowed down.
Reporting is generated, not written.
An executive summary, a PDF, a CSV — assembled the moment a run finishes, not compiled by hand afterward. Confidence comes from a system that can't flatter itself: coverage insights narrate deterministically computed numbers.
- Plain-English summary, key risks, and trend versus the prior run
- CSV export and a formatted PDF for manual rounds
- Coverage dashboard — a suite that only tests happy paths is immediately obvious
By the time the sign-off call starts, there's already a one-page summary: 18 passed, 1 failed and classified, trend versus last Tuesday's run — exportable to PDF for whoever isn't opening the dashboard.
Someone stays late the night before a release, compiling results from three separate tools into a slide.
The report exists the moment the run finishes — nobody assembles it by hand.
With coverage proof and a prioritised risk list — ready for the sign-off call.
The build goes back with evidence attached, not a verbal "looks fine." Coverage proof, an evidence trail, and a prioritised risk list mean the sign-off call starts from facts, not from memory.
- Coverage proof — gaps are surfaced, not hidden
- Every defect carries a screenshot or recording
- Known issues tracked separately from real blockers
The release note for forgot-password ships with: 19/19 automated cases green, 3 manual cases signed off, one known issue tracked separately as flaky rather than real — and a coverage screenshot proving edge cases weren't skipped.
"Are we good to ship?" gets answered with a gut feeling and a half-remembered test run.
"Are we good to ship?" gets answered with a number, a list, and evidence attached to each line.
Ship your first build.
Point Pulse at a URL, upload an APK, or drop in an FRS document. Watch the test hierarchy build itself.
Get Started →