Thunders News Center

Writing test cases for a new feature used to mean opening a blank case for the first flow, then repeating that for the second, the third, the tenth. Not anymore.

• One request, many cases: ask Thunders AI to create several test cases at once, from a doc, a live page you've asked it to browse, or an attachment you drop in.
• Each one reviewable on its own: every test case comes back as its own result, so you approve or edit one without touching the rest.
• Grounded in what you gave it: the cases it writes trace back to the context you handed it, not a generic template.

If a feature ships with five user-facing flows, that's five test cases from one request, not five separate conversations.

#Sprint30

A run kicked off from CI, or one still going in the background while you worked on something else, used to be invisible until it finished. Now you can just open it.

• Live, mid-execution: open any running test run, including ones triggered from CI, and follow it step by step as it happens.
• Not just your own: anyone else watching that run gets the same live stream.
• No more waiting on faith: know whether a run is on track without waiting for the summary at the end.

If a CI run runs long, you can check in on exactly where it is instead of waiting for the notification.

#Sprint30.

A test case could change under you, with no record of who did it or why. Now there is one.

• Full edit history, on the case itself: open the Activity tab on any test case to see every change, newest first.
• Every author attributed: a person, Thunders AI, CI, or MCP, even when they're acting on your behalf.
• Tied to the run that used it: a run's own Activity tab shows the test case exactly as it stood at that run, not as it looks today.
• Down to the step: expand a step edit to see exactly what changed inside it.

When a test that passed last week fails today, you no longer have to guess whether the app changed or the test did.

#Sprint30

A run could fail on a test case you own, and you'd only find out if you went looking for it. Now there's a place that finds you first.

• One place for what needs you: Thunders now has an Inbox in the main navigation, starting with failed runs.
• Enough context to act: each notification carries the test case name, the run result, and a link straight to the run.
• Read and unread, tracked: know at a glance what you've already seen.
• Routed to the right owner: when the failure comes from a shared module, the module's owner hears about it, not the owner of the test case that used it.

It starts with failed runs. It's built to hold a lot more over time.

#Sprint30

We didn't redesign the sidebar to make it prettier. We redesigned it because a growing product needs a clear point of view about what matters most.

• Focus over completeness: the things you touch daily, your organization, your projects, sit at the top, one click away. Everything else moved out of the way instead of competing for the same space.
• Polish in the details: a searchable project switcher instead of a scroll list, profile and account controls settled into one footer instead of floating wherever they used to sit.
• Less is more, on purpose: seven separate settings tabs collapsed into one Configure entry. Nothing you could do before is gone, it's just not seven decisions to find it.
• One structure, not several: organization, projects, and Thunders AI now sit in a single, consistent hierarchy, instead of each having grown its own shape over time.

This is the shape we want the rest of Thunders to grow into: the daily surfaces upfront, everything else organized and out of your way, not fighting for your attention.

#Sprint30

Filing a bug from Thunders used to mean a form: one project, a handful of fields it exposed. Getting Thunders AI to read anything back from your tools wasn't possible at all. Both changed.

• Connect a tool: from Connectors, or the connect-tools shortcut inside Thunders AI. Covers Jira Cloud, Confluence Cloud, Azure DevOps, Linear, Notion, ClickUp, and Shortcut. Xray and the Data Center integrations are unchanged.
• Set guidance once per tool: "put it in triage, severity high, assign to me," and every bug Thunders AI files into that tool follows it, no retyping it per report.
• Read from your tools, not just write to them: ask Thunders AI to pull in a spec or look up an issue, then write a test grounded in what it found.
• Bring your own connector: don't see your tool listed? Add its MCP server yourself. It works the same way as a native one.
• Your own connection, not the project's: a connection used to be shared with the whole project, so one person's login carried everyone. Now each person connects their own account.

This is what makes Thunders AI a colleague that can act on your tools, not just talk about them.

#Sprint30

A Thunders AI conversation used to disappear the moment you closed the panel, unless it happened to end in a test case. Now it's kept.

• Every conversation is listed: not just the ones that produced a test case.
• Rename them: give a session a name that means something to you later.
• Resume where you left off: reopen a past conversation and keep going, instead of starting over.

If you were mid-investigation and got pulled away, the conversation is still there when you get back to it.

#Sprint30

Thunders AI used to live in its own panel, outside the plan or set you were actually building. Now it's part of the surface itself.

• Open it right from the plan or set: no jumping out to a separate chat and back.
• Add sections to the plan: ask it to help structure the document as you go.
• Create test cases linked to the plan or set: every case it creates is already wired to where it belongs.
• Scenario generation stays yours to trigger: this phase covers structure and case creation, not automatic scenario generation. That's still a deliberate step you take.

This is phase one of folding Thunders AI into the planning surface itself, not leaving it as a separate tool next to it.

#Sprint30

Running a batch of test cases together used to mean one data file for the whole batch, shared across every case whether it fit or not. Now each case brings its own.

• Attach the file to the case, not the batch: every test case in a run carries its own data source.
• Dozens of scenarios, one launch: run a large batch where every case pulls from its own file, all in a single execution.
• No manual wiring: skip hand-building iterations to fake per-case data, the platform does it natively.

This is what makes data-driven testing scale: a batch of a hundred cases can now mean a hundred different data sets, not one shared compromise.

#Sprint30

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