Thunders News Center

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.

A test case isn't a static thing. It's drafted, reviewed, approved, eventually retired. Thunders now tracks that.

• Four states: mark a test case as Draft, Ready, Approved, or Deprecated as it moves through your review process.
• Status snapshot on execution: every run captures the lifecycle status at the moment it ran, so you always know which version of a test was executed and whether it was approved.
• Auditable history: results stay tied to the exact version of the test that produced them, even if the test changes afterward.

For teams with formal QA processes (approvals, audits, compliance), you can now treat test cases like any other reviewable artifact. For everyone else, it's a clearer signal of which tests are battle-tested versus which are still in progress.

#Sprint27

A handful of follow-ups on API testing

• Raw response view: inspect the raw API response alongside the pretty view, and export the body as JSON.
• Variables in assertions: use variables in API assertion values, so you can compare against extracted or dynamic data.

These make API test steps more debuggable and more flexible when validating responses that depend on context from earlier steps.

#Sprint26

Files downloaded during test executions can now be added to your Test Assets directly, via right-click or hover actions.

No more downloading files locally and re-uploading them. If a test produces a file you want to reuse (as a reference, a comparison baseline, or input for another test), you can save it to your Test Assets in one click.

#Sprint26

Test Sets and test cases now execute in alphabetical order by name when parallelism is set to 1, giving you predictable, repeatable run sequences.

If you rely on a specific execution order (for example, a setup test that must run first), you can now name your test cases accordingly and know they’ll always run in that order. No more guessing which test goes next.

#Sprint26

A new File Compare step lets you compare simple CSV files side by side within a test. Upload a reference file and the step highlights the differences automatically against the test-generated output.

Use it to validate data exports, regression-check reports, or verify that extracted tables match expected baselines. No scripting required: just drop in your reference CSV and the step does the rest.

#Sprint26