Lead QA here, mobile and web automation (Appium, Espresso, Selenium). Curious how other teams handle the gap between a story being picked up and test cases actually existing.
Ours is manual: when a ticket comes into play I read through it, work out what’s affected and what regression risk it carries, write the manual and automation cases, then move them into the board by hand. It works. It also eats a few hours a week, and most of that isn’t the thinking part — it’s the transcribing.
What I’d like to know from you:
Do you plan tests per story/ticket, or at the feature or release level?
Who writes the cases — QA, the dev, both?
Where do they live: TestRail, Jira, spreadsheet, informal?
How do you scope regression when a change hits a risky area — judgement, coverage data, or a fixed suite?
Happy to go into detail on our setup if useful, particularly the mobile side where the Appium/Espresso split creates its own overhead.
Mainly I want to know whether the manual portion is just the job, or whether some of you have engineered around it.
I think the manual part isn’t really writing the test cases. It’s translating the same understanding across multiple tools.
We mostly plan testing at the story level but we always keep the feature context in mind because that’s what usually drives regression risk. A story might look small on paper but can touch a critical workflow.
QA owns the test design, although discussions with developers happen early if the implementation introduces new risks or edge cases. Our test cases live in a test management tool that’s linked to Jira, so we maintain traceability between requirements, execution, and defects.
For regression, we don’t rely on a fixed suite alone. We start with risk assessment:
Which modules are impacted?
Are there shared services or APIs involved?
Has this area historically been unstable?
What is the business impact if something breaks?
That determines whether we run only the core regression suite or expand it with targeted tests.
The biggest overhead isn’t deciding what to test it’s keeping stories, test cases, automation, and tracking tools in sync. That’s the repetitive work I wouldd like to see reduced. Test design benefits from human judgement, copying that design into multiple systems doesn’t.
the part i’d automate is the translation, not the test design.
i’d keep one reviewed risk note on the story, generate the initial case set from that, then let each run produce its own evidence. the test case says what should happen; the execution artifact shows what actually happened. those are different objects, and forcing both through jira, a test manager, and the automation repo is where the sync tax starts.
for your appium/espresso split, which system is currently the source of truth when the same risk is covered in both?
Your process sounds very familiar. We also create test cases at the story level because it gives us better traceability, while our regression scope is mostly based on the risk and impact of the change rather than running the entire suite every time. We keep the detailed test cases in a dedicated test management tool that’s linked with Jira, which helps reduce duplicate work and keeps everything connected to the original story.
The manual thinking part is still valuable, but the copying and organizing definitely feels like overhead. Even outside QA, I’ve seen the same pattern in other industries, for example, packers and movers can automate scheduling and tracking, but someone still needs to plan the move itself. I think test design is similar: automate the repetitive tasks and spend your time on the analysis that actually adds value.
when it comes to regression scope we plan and prioritize risk based testing , meaning running the right 20% of tests to catch 80% of bugs , now using AI we try and identify which are those 20% of tests based on change frequency, historical defects, code complexity , business impact and how may tests we actually have more of data-driven analysis…instead if guessing the impact , stale checklist
@komalgc I was wondering how to learn to do all that. Is there any blog or course which can give me a high level overview, perhaps by using an active open source project as an example?
“It works. It also eats a few hours a week” is such a relatable line. The hand copying from cases into the board feels like the part nobody ever budgets time for. Zara, did you ever find anything that cut that down, or is it still a manual shuffle? And John, with your tool linked to Jira, does it actually stay in sync over time, or does it drift once the story changes?
i tired of seeing llm generated scenarios that qa than runs with claude/playwright, and messy bug reports that come out. The avalanche starts with a small things.
1 - depends, might be story/ticket or epic/feature or bunch of tickets/release scope (AI does)
2 - AI
3 - Informal + AI memory (short high-level checklists often described in tickets for visibility and managers)
4 - AI, based on code changes
Note: You need to build proper AI memory/context/setup first
This is really clarifying — sounds like we’re all circling the same thing: the design work is fine, it’s re-typing it into Jira, the test tool, and the automation repo (and keeping them from drifting) that quietly eats the hours.
Curious how deep that pain runs for you:
Have you tried a tool that holds one source of truth and pushes to the others? Did it stick, and if not, why?
If something genuinely killed the re-copying and the drift, is that a “nice-to-have,” or something you’d push your team to actually pay for?
Dwayne — your “one risk note → generated cases → each run produces its own evidence” is basically the dream. What’s stopped you adopting or building that already?
