Regression, Mobile & Stakeholder Comms.

Stop guessing what a change might have broken.

Trace it instead.

You can never re-test everything on every release, so the judgment call about what a change might have affected is the whole job. Walk AI through a shared-logic change and it helps you map where else that logic surfaces. Walk it through a permissions change and it helps you think through the more dangerous failure mode: not what breaks visibly, but what becomes visible to someone who shouldn't see it.

I have a change shipping and I need to know what it could break besides
the obvious thing.

What's changing: [describe the change]
What else touches the same code, data, or component: [list anything you
know shares this, a shared function, a shared table, a shared UI
component, anything]

Trace this out for me: if this change has a bug in it, what's the
farthest-away place that bug could show up, not the screen where the
change was made, but somewhere else in the product that quietly depends
on the same thing changing?

Rank what you find by how likely someone is to actually notice it
broke, from "immediately obvious" to "silently wrong for weeks before
anyone catches it." The second category is the one I actually care
about, don't bury it at the bottom.

Developer release notes are written for engineers, not testers. This turns them into an actual QA test focus in five minutes.

Brief AI on what mobile actually breaks.

Stop getting generic coverage.

The generic test cases AI produces by default are usually web test cases with "on mobile" appended. That's because AI doesn't know what makes mobile different unless you tell it. Brief it on the risk areas mobile actually introduces:

• Interruption handling: what happens to a half-finished form when a phone call comes in, the app gets backgrounded, or battery saver kicks in mid-flow
• Touch target accuracy: taps, swipes, and fat-finger misses on controls that were sized for a mouse cursor
• Platform permissions: camera, location, notifications, and what the flow does when the user taps "Don't Allow"
• Network conditions: the flaky connection, the mid-request signal drop, offline and back again
• Device fragmentation: the same screen on a three-year-old budget Android and a new iPhone: different sizes, OS versions, rendering

One line in your prompt changes the output. "Test the checkout form" gets you web cases. "Test the checkout form on iOS and Android, covering interruptions, permission denials, and flaky network" gets you mobile cases.

Translate findings into language that gets acted on.

You have to communicate what you found, how serious it is, and what you recommend, to people who don't want to read a long report. AI can turn a technical finding into risk-and-impact language a non-technical stakeholder will actually act on: release readiness reports, escalation messages, and calm, evidence-based responses when a developer pushes back on a bug you filed.