Thunders News Center

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

Pixel-perfect comparison is rarely what you want. Real screenshots have placeholder data, timestamps, and mock content that shouldn't fail a test. Now you can tell Thunders what to ignore.

• Custom guidance prompt: add an Instructions field on the visual compare step telling Thunders what to focus on or what to ignore (like placeholder data in your mockups).
• Improved UI: the step now has a clearer interface with the Instructions field front and center.
• Less rigid, more useful: the AI weighs your guidance when deciding pass or fail, so real-world tests don't break on cosmetic noise.

Use it when your design mockups have lorem ipsum, your test environment shows different user names, or your screenshots include timestamps. You define what matters, Thunders compares accordingly.

Reporting a bug from Thunders used to drop a thin ticket into your backlog: a vague title, a screenshot, and not much else. Now every reported bug arrives with everything your team needs to fix it.

• Cleaner structured format: every ticket follows the same shape (Error, What Happened, Environment, Steps to Reproduce, Evidence, AI Reasoning).
• Full evidence attached: screenshot at failure, pre-failure screenshot, console logs, browser URL, device, environment, and timestamp, all pulled automatically from the test run.
• Scannable title format: new ticket titles follow [Severity] IssueType on Element | TestCaseName, so your team can triage at a glance from the backlog view.
• Reported with Thunders footer: every ticket signals it was auto-generated with full context, with a link back to the source.

Works across Linear, Jira, ClickUp, Shortcut, Notion, and Azure DevOps. A developer (or an AI agent) opens the ticket and has everything they need: where it happened, what the page looked like before and after, what the console said, and what the AI was reasoning about when it failed. No back-and-forth required.

#Sprint27

Until now, Thunders Copilot lived in test authoring. Now it lives where you debug too.

• Open Thunders Copilot from any test run: the chat panel is available directly inside the test run view.
• Ask about the run you're looking at: request an explanation of a failure, a summary of results, or an investigation of specific steps. Thunders Copilot has full context on what happened.
• Per-run history: conversations are persisted per test run, so each investigation stays focused and separate.

When a run fails and you're trying to figure out why, you don't have to leave the page or recreate context. Ask Thunders Copilot in place, and it knows exactly what you're looking at.

#Sprint27

Some test environments need setup that's not really about the test itself. A captcha to bypass, a tracker to silence, a flag to flip. Init Scripts handle that.

• Per-environment configuration: define a custom JavaScript snippet on any environment from environment settings.
• Runs automatically: Thunders executes the script before every test in that environment, no manual setup per test case.
• Common use cases: bypass client-side captcha and anti-bot gates, disable or stub analytics and trackers, or pre-seed feature flags.

If you've been working around a captcha in dev, polluting your analytics with test traffic, or manually toggling feature flags before each run, this handles it cleanly at the environment level.

Sometimes the test you want lives in a document. A spec, a PDF, a CSV of test data, a screenshot. Now Thunders Copilot can read it.