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