Is it possible to engage business on reviewing regression test pack/high level test scenarios? What is an effective way to do this?

The objective is to align the current regression test pack with business’ expectations in terms of requirements/system behavior. Most likely some of tests we have are already outdated, so we need to find a way on how we can start maintaining them.
What is the most effective way to do this? If you have done something before, please walk through the process/action items/outcome from this activity

Thank you!

2 Likes

The objective is to align the current regression test pack with business’ expectations in terms of requirements/system behavior. Most likely some of tests we have are already outdated, so we need to find a way on how we can start maintaining them.

Start updating and maintaining your regression test suite. If the business doesn’t want to provide resources, time, or approval for these activities, then explain to them the risks: you may encounter many issues and bugs that could dramatically affect business goals and user experience. If they are okay with these risks, then at least this responsibility won’t fall on you.

If you need active participation from stakeholders, tell them why and convince them of the importance. Again, explain the risks: numerous issues and bugs could significantly impact business goals and user experience. If they accept these risks, then at least this won’t be your responsibility.

If businesses believe that quality is less important than other matters, they may have strong reasoning. They might be mistaken, but the only thing you can do is perform your job as well as you can, fully inform them about the risks and problems, and get their approval. Other strategies would require additional time and resources, and if the business doesn’t provide these, you can’t implement changes; you can only continue to negotiate. You may be able to make minor adjustments to your work process to free up some resources for maintaining the regression suite, but this depends on your specific context. Dealing with old bugs, adding improvements, refactoring legacy code, writing docs and automated/unit tests are all part of the development process as the point you asked about. If you don’t have the resources, and the business doesn’t agree with you, you can only remedy some symptoms.

3 Likes

I’m curious…

Who’s objective is it? And what’s the final target? are explicit requirements non-existent? or spread all over the place and hard to find? is the team shifting often and knowledge lost? are testers beginners so can’t test without explicit scripts(requirements or cases)? does the product change too often and no one is writing down how - which is a problem for some people?

I assume you mean written scripts. Why would you need to rewrite them?
Is business rewriting requirements, keeping updated the specifications, updating their use-cases?
Are developers consistently documenting their implementations or choices of solutions or workarounds?

Do you generally have an alignment problem? do testers work regularly with the business or completely separate? are testers missing some information that the business has, explicit or implicit? are testers included in the software cycle only at the end? are there trouble of understanding requirements from the development team as well?

’ Is it possible to engage business on reviewing regression test pack/high level test scenarios? What is an effective way to do this?’
Why would testers have the business people review their interpretations of the requirements(in scripted cases/checks/scenarios)?
And not the other way around: business requesting testers to test their written specifications/interpretations of the requirements that they’ve obtained from customers/stakeholders. And keep those regularly up to date…

1 Like

Welcome to the community @jmrvls , you are now in the only and best Software QA community.

Yes, stale tests are a problem many have faced before. See also some of the discussion tangents in

When people ask this question I get the impression they are testing a non-web product, and they are testing the entire product and not focusing on features. Both of these kinds of work are expensive and exhausting, if… if there isa priority or order in which tests get executed, I would look at using that. Any tests at the end of the run and lower down, are probably not worth running every time, and that’s what I would be culling if possible. Giving tests priorities or ordering helps a tonne.