Thunders News Center

Every Thunders Test Case has lived in the browser. Mobile testing changes that: the same natural language approach, now pointed at native Android apps.

• Native OS actions: control device state mid-test straight from the step editor, GPS and location, WiFi, Home, and app launch.
• Real hardware, not emulators: tests run on real Android devices (Galaxy S25 and S25 Ultra, Android 15+), so results reflect what your users actually see.
• Thunders Copilot goes mobile: Thunders Copilot can now author and edit mobile Test Cases, the same natural language flow you already use on the web.
• Alpha, feature-flagged: we're onboarding a small group of teams first, so we can shape this with real usage before it opens up more broadly.

If you've been waiting to bring Thunders to your Android app, this is the moment to try it early. Reach out to us to get access to the mobile alpha, and tell us what's now possible for your team, and what's still missing.

#Sprint28

Recording used to be a straight line. If you missed a step, you had to finish the recording and fix the order afterward. Now you can insert it right where you need it, without stopping.

• Insert anywhere in the flow: while recording is active, add a new step at any point, not just at the end.
• Recording keeps running: the timer keeps going and capture continues from where it left off, no need to stop and restart.
• Position stays intact: the inserted step doesn't disrupt where you are in the flow, the rest of the recording continues exactly where you left it.

#Sprint28

Analytics scripts, live chat widgets, and font providers keep connections open long after your page is actually ready. Thunders used to wait for all of them anyway, on every single step.

• Build an allowlist, per project: add domains to skip during page-load checks, right from Page Stability Settings.
• Wildcards supported: use patterns like .analytics.com to cover a whole subdomain family in one entry, up to 50 domains per project.
• Only page-load checks are affected: everything else about how your tests run stays the same, you're just telling Thunders which connections aren't worth waiting on.
• Set once, apply everywhere: every test run in the project uses the same allowlist, no per-test configuration.

If a run has ever timed out on a page stability check even though the page you cared about loaded fine, a background analytics call or chat widget was probably still open. Add the domain once, and Thunders stops waiting on it across every future run.

#Sprint28

Test Case's owner used to be locked to whoever created it, months or projects ago. Now you can change it whenever responsibility actually moves.

• Change it from two places: update the owner from the Test Case editor's properties panel, or right from the Owner column in the Test Cases list.
• See ownership at a glance: the Owner column shows an avatar and name for every Test Case and Test Run.
• Sort and filter by owner: group the list by team member to check workload, or filter down to just the Test Cases one person owns.
• Any admin or member can reassign: no approval step, the change takes effect immediately.

When someone leaves a team or work gets redistributed, reassign the Test Cases that matter instead of leaving them tied to whoever created them months ago. It's also what makes routing a failed run to today's owner possible, not last quarter's.

#Sprint28

Every mainstream test automation tool ships an escape hatch for logic a UI step can't express. Thunders now has one too.

• Write and edit in place: the JavaScript Step opens a code editor directly in the Test Case, with a locked function scaffold so the contract with the runner can't break by accident.
• Full context, not just the page: read and write Thunders variables, query the DOM, call APIs, and read console output, all from inside the script.
• Structured pass or fail: return a clear success or a failure with a reason, and see the result, logs, and any errors in a dedicated panel as soon as the step runs.
• Same variable syntax: reference [variables] inside your script exactly like any other step.

Catch what pure UI testing misses: read the total shown on a cart page, call the API for that same cart, and fail the step if the two disagree. The page can render fine while the backend is wrong, a JavaScript Step is what catches that.

#Sprint28

Test Cases already ran alphabetically if you dialed parallelism down to 1. We upgraded that into a real mode: an explicit Sequential option with its own say in what happens when something fails.

• One click in the Execute modal: pick Sequential instead of Parallel for any Test Set, Test Case selection, or group of Test Sets.
• Predictable order: Test Cases run one at a time, alphabetically by name, so a step named 01_Login always runs before 02_Create_Report.
• Continue or stop on failure: choose whether the run continues through every Test Case for the full picture, or stops at the first failure and skips the rest.
• Same rule at every level: run multiple Test Sets sequentially, and each set's own cases run in order underneath.

Use it for dependency chains like Create, Edit, Delete, where each step needs the last one's result. Prefix Test Case names with numbers (01_, 02_, 03_) to pin the exact order, and pick Stop when a failed step leaves nothing left to test.

#Sprint28

File Compare already reads text across two files, even different types, a PDF against a DOCX, a contract against its template. The upgrade is how you see the results: a new dual-pane viewer lays both files side by side, with every match and mismatch highlighted right where it happened.

• Both files, side by side: File 1 and File 2 open in a dual-pane viewer instead of a flat list of findings.
• Matches and mismatches highlighted: each result is marked directly in the file where it was found, so you see the difference in context, not just a description of it.
• Click a finding, jump to it: select any Passed or Failed result and both panes jump straight to that spot.
• Works across file types: PDF against DOCX, CSV against CSV, whatever pairing your test needs.

Currently in beta.

#Sprint28

A prerequisite Test Case could already gate a Test Set, stopping everything downstream if it failed. What it actually produced along the way just disappeared. Now it doesn't have to.

• Generate at runtime: capture a token, an ID, or session data from an API call or a login flow inside your prerequisite Test Case.
• Available downstream: reference those values in every Test Case that runs after it in the same Test Set, no need to regenerate the same data twice.
• Still gates the run: this builds on the pass/fail gating you already have. The prerequisite still has to pass before the rest of the set runs.

Log in once at the top of a Test Set, capture the session token, and every Test Case after it reuses that same session instead of logging in again. The same pattern works for any setup step whose output the rest of the suite needs.

#Sprint28

API steps now handle the request bodies real APIs actually expect.

• Multipart/form-data body type: select multipart/form-data from the body type dropdown in any API step.
• File uploads in API requests: attach files as part of the request body for endpoints that expect file uploads.
• Mixed payloads: combine file fields and form fields in the same request, with no manual encoding.

If you've been blocked on testing file upload endpoints, document submission flows, or anything that expects multipart payloads, the API step handles it natively now.

#Sprint27

Xray integration gets a meaningful upgrade in both directions.

• Xray Data Center support: connect Thunders to your self-hosted Xray instance as a native integration, alongside the existing Xray Cloud support.
• Sync results back to Xray: click "Sync to Xray" on any test run detail page to push execution results directly into the originating Xray ticket.
• No more copy-paste: stop manually updating Xray with test outcomes. Thunders writes results back where they belong.

If you manage tests in Xray and execute them in Thunders, your Xray tickets now reflect what actually happened, automatically. The full round trip works for both Cloud and Data Center.

#Sprint27