Thunders News Center

You can now export a run report directly from a Test Set or Test Plan. Previously, PDF export was available only from the Test Runs view.

• Open the Runs tab in a Test Set or Test Plan and export any run to PDF.
• Use the same PDF report available for an individual run.

Get the report you need without opening the run first.

#Sprint31

Your RGAA report just got more complete and more precise, with no extra work on your side.

• 16 more RGAA criteria are now covered, closing gaps that used to come back untested.
• Color contrast issues are now reported against the exact RGAA criterion they affect, instead of one blended result covering several at once.
• Image alt text is reviewed for whether it's actually meaningful, not just whether it's present, catching irrelevant or wrongly-empty alt text too.

A more complete, more precise RGAA report, without lifting a finger.

#Sprint31

Deleting or copying the steps inside a test case used to mean working one at a time.

• Select multiple test steps at once in the Test Case Editor.
• Copy or delete them together, instead of one by one.

#Sprint31

A test set used to run its cases in whatever order they were added.

• Turn on Reorder inside any test set to decide the order its test cases run in.

A small change, but it adds up when you're maintaining a test set with dozens of cases in it.

#Sprint31

A failed connection to your app used to just fail. Now Thunders tells you why.

• DNS doesn't resolve: Thunders says so, and suggests a fix if the hostname looks like a typo.
• A TLS problem: see the exact certificate issue, with an optional setting to ignore HTTPS certificate errors for testing.
• A timeout or refused connection: get pointed at a likely firewall issue, with our egress IPs ready to copy into your allowlist.
• An HTTP error from your app itself: a 401 points you at your credentials, a 5xx suggests checking the app is actually up.
• A captcha blocking the login step: a guided card walks you through adding a bypass flag to your app, and turning it on.

Instead of a generic failure, you get pointed at the actual problem, and usually a way to fix it on the spot.

#Sprint31

Mobile testing has been picking up real capability, sprint over sprint.

• Run tests on iOS, not just Android: upload an .ipa and pick your devices.
• The Accessibility persona now runs on iOS and Android too, with the same report you already get for web.
• Devices are routed by region and show their real geography instead of a provider suffix.
• Watch the actual device streaming live in the preview panel, from the moment it's warming up through the end of the run, instead of only post-hoc screenshots.

Mobile is no longer the smaller sibling of web testing, it's catching up fast.

#Sprint31

A project or environment variable used to hold whatever value you typed in, until you went back and changed it by hand.

• Mark a variable writable and a step in your test can update its value, or clear it, mid-run.
• The change is saved on the project or environment itself, not a local copy, so every other test case and run that references it sees the update too.
• See how fresh a value is: the run view shows how long ago a variable was last written.

A variable can now reflect what your last run actually produced, not just what you set it to weeks ago.

#Sprint31

Execution settings, browser, resolution, device, proxy, ignoring a certificate error, used to live only on individual test cases. There was no way to set a default for a whole environment, so every new test case started from scratch.

• Give an environment its own Web and Mobile settings profile.
• Every test case that runs there inherits it automatically.
• A test case with its own saved settings keeps them, the environment default only fills the gap.
• A fix accepted during environment setup, like ignoring a certificate error, is saved straight into the profile from then on.

One setting, saved once, instead of repeating it across every test case that touches that environment.

#Sprint31

A test that fails three steps in used to mean rerunning the whole thing from the top just to see what happens at step four. Not anymore.

• Set a breakpoint on any step in the Test Case Editor.
• The run pauses there instead of continuing past it, with a countdown before it resumes on its own.
• Resume when you're ready, from the exact step you paused on.
• Edit a step behind an active breakpoint and the run restarts to reflect your change.

Debugging a flaky step stops meaning rerunning the whole case just to get back to the part you actually care about.

#Sprint31

Getting a test set to run on a recurring cadence used to mean wiring up your own CI job to trigger it on a cron. Now Thunders can do that natively.

• No CI required: schedule a test set to run on a recurring cadence directly from Thunders.
• Vary the run: schedule the same set across different environments, personas, or both.
• Managed right where you already work: schedules live on the test set itself, next to its regular run history.

A regression suite no longer needs a CI job of its own just to run on a schedule.

#Sprint31