Thunders News Center

Running a Test Case with the Accessibility persona used to mean a separate report for every step. Piecing together the full picture was your job. Not anymore.

• One report for the whole Test Case: set the persona's reporting mode to Summary reports and get a single end-of-run report instead of one per step.
• Everything in one place: read the complete accessibility picture for the flow you tested, in one document.
• Per-step mode stays: keep the step-by-step reports if that's what your process needs.

For audits and compliance reviews, one comprehensive report per Test Case is the artifact you actually hand over.

#Sprint29

Mobile testing is in private beta, free over the summer. Here's what's new this sprint.

• Device pools and a catalog: manage a pool of test devices, browse the catalog, and pick a pool right from the Test Case editor or when queuing a run.
• Execution settings that stick: save a cellular toggle and per-permission choices on a Test Case or run.
• More device-state control: on top of GPS and Wi-Fi, steps can now toggle Bluetooth, NFC, Location, and Data mid-test.

Reach out to customer support or your Customer Success Manager to get it activated for your team.

#Sprint29

A Test Plan could already generate Test Cases from the doc. What it couldn't do was run them together as the plan itself. Now it can.

• Execute the plan directly: run a Test Plan with the Test Cases you've selected, the same way you run a Test Set.
• Plans get an owner: the same ownership model Test Sets just got, defaulting to the creator.
• Cases listed on the plan: see every Test Case that belongs to the plan, right where the plan lives.
• The document is unchanged: you author plans exactly the way you did before.

Write the plan, generate its Test Cases, and run the whole thing from one place, no separate Test Set required.

#Sprint29

Thunders AI could only reach the tools we built connectors for. That list is gone.

• Bring your own connector: add any custom MCP server, with its own auth method.
• First-class tools: Thunders AI uses your server's tools the same way it already uses Notion, Linear, or Jira, to write tests and report bugs.
• Tune it per connector: every connected source has its own settings page where you can view and edit its guidance text.

If your team runs an internal tool with an MCP server in front of it, Thunders AI can now work with it directly, no waiting for us to build the integration.

#Sprint29

Thunders Copilot was the right name for where we began. Thunders AI is the right name for where we're going: one place to understand, investigate, manage, and execute across Thunders.

• Everywhere in the app: every label, tooltip, and prompt now says Thunders AI. All the same capabilities, nothing to relearn.
• Report bugs without leaving the conversation: report a bug from a test run, or just ask in chat, and a ticket-creation thread opens with your connected integration.
• Straight to your tracker: works with Notion, Linear, Jira, ClickUp, Azure DevOps, and more.

The assistant you knew keeps growing into a colleague inside the product. The name now matches the ambition.

#Sprint29

The gap between what you meant and what you wrote is where natural language breaks. Thunders now catches it before and after every run, so you're not the one fixing it, now or later.

• Before you run: get suggestions that tighten up ambiguous test steps, before they ever touch your app.
• After the first run: get richer suggestions once your test case has executed, grounded in what your app actually does.
• You stay in control: these are suggestions, not silent rewrites. Review each one, apply it or dismiss it.
• On for everyone: pre-run and post-run suggestions are now generally available, no flag to flip.

"Click on blue" can pass today and still break the day a dev ships a second blue thing. Coaching closes that door while you're writing, so the fix never lands in your backlog.

#Sprint29

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 Beta, 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