Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

I pretty sure that most of you guys have reached this at a given moment in time. That moment when your regression tests keep piling and also the amount of time it takes to go through them also increases.

When to decide to descope some items?

I know that it mostly depends on what parts of the code have been touched, but for the sake of argument let`s assume that the feedback from the Devs is not really helpful.

share|improve this question
    
I take it your regression tests are all manual and have not been automated? –  Phil Kirkham Jul 3 at 19:12
    
The app that were currently working on, is based on some prehistoric code and it had no automation assigned to it then. As were replacing bits and parts of the code now, we`re getting resources assigned to that, but again, baby steps on that front as well. –  AndreiT Jul 3 at 19:27
    
If it's an old legacy app does that mean you can find out what parts of the system the users actually use and what parts they never touch? –  Phil Kirkham Jul 3 at 19:40

2 Answers 2

up vote 3 down vote accepted

In two words- Risk analysis.

In a few more words- risk is usually defined as the probability of something going wrong multiplied by the damage caused by this something actually going wrong.

Now you can use this definition to come up with more specific guidelines like-

Is this feature stable ?

Is this feature dependent on other less-stable features ?

What will happen if this feature fails in a subtle/medium/catastrophic manner ?

share|improve this answer
    
I agree, a risk assessment should be implied when deciding this. Though it might be tough when youre dealing with an app like lets say a ecommerce website where everything is related to eachoter(more or less). Thank you! –  AndreiT Jul 4 at 7:25

Ideally if a feature (or feature interaction) is no longer in use by end user, only those feature cases should be removed.

However we do not live in ideal world. We have timeline and resources constraints and as you have rightly pointed out, reducing regression time is seen as first level of action to mitigate it. If all other actions of reducing regression time (like optimizing execution, using additional resources when they are not in use ,say on weekends, or during night time) one should consider managing regression case count so that time required by additional regression cases is compensated by reduction of not-so-useful cases.

Guidelines for de-scoping should be

  1. The features which are stable, that is no bugs have been reported by regression tests or by end user in last few iterations/releases.
  2. Not to de-scope all cases of the feature, have at least a case (which is most complex or covers maximum scenarios) in regression suite.
  3. If bandwidth permits and nature of testing allows combine or merge those cases in single case to ensure feature coverage is still intact.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.