regression : when the highly unlikely happens

May 29, 2010

regression : when the highly unlikely happens

i’m not a profoundly unfit person ( physical health wise 🙂 ) but i have been bitten by the “get fit” bug lately.

as part of my daily routine i go for atleast a 3 km run . I follow a path along roads and larger streets .

normally i do some basic tests at each intersections and street ends for cars,pedestrian lights etc

and according to my risk analysis there are some low/no activity areas where in i just whizz past 🙂

The other day , at a deserted no exit street I was in my usual whizzing past mode ( because I had been lulled into a false sense of security from my previous month of experience on this street) when a car suddenly seem to appear from now where and I almost got run down !

This being NewZealand, the driver apologized , in fact it was my mistake since I was being careless and I also waved and apology back .

No real damage done and I moved on .

But this episode got me thinking about a testing parallel –

what happens if due to a seemingly unrelated change a break in an existing “stable” functionality happens or our perception of any existing “stable” functionality is proved wrong.

Obviously, first reaction would be fire fighting and counter the situation .

but what would be our strategy afterwards

Do we –

1. just put the fire out and move on thinking ” this would not happen again ” ” once in a blue moon” “we can not control or predict such highly unlikely event”

2. Do we tighten our regression detection just for that functional area ?

3. Do we tighten our regression detection just for all “stable” functional area ?Raise our regression guard one level up ?

4. Do we re visit our impact analysis and see what went wrong in our understanding of the change’s impact ?

dear readers ,your thoughts on this ?

Testing/Leading

Posted by:

thereluctanttester

2 responses to “regression : when the highly unlikely happens”

Upjitpal Ghuman

May 31, 2010 at 2:56 pm

For all the perceived stable functional areas, developers will always be careless because they are perceptive by nature. Testers, however, should have stopped any faulty enhancement from getting into the production.

As an account manager, and a subscriber of the above belief, my first reaction would be to identify that one throat to chock – and chock it really hard. And more often than not, in such cases it will be of one of the testers 🙂

But on a serious note, I think, the reaction could be option 1 or any combination of options 2, 3 and 4 (as they are not entirely mutually exclusive) – depending upon the severity with which the business got hit.

Reply
1. thereluctanttester
  
  June 1, 2010 at 7:25 am
  
  thanks Upjit, for bringing in the business angle.
  
  whilst I agree one of tester’s prime focus is keeping an eye on regression seeping into production.
  
  I would suggest that before decapitating a tester , project owners should look into the context and reasons of the failure and then find a scape goat 🙂
  
  having said , I was mainly pondering upon situations where in “highly unlikely ” regression occurs or our risk analysis fails rather our beliefs based on risk analysis fail.
  
  I agree with you choice of a combination of both 2,3 and 4 depending on technical and business context of the loss.
  
  I would be very reluctant to do just 1 ( inspite of what ever the pundits say about the black swan etc ) I think these things can always jumpback and bite your back side even if they are deemed dead 🙂
  
  Reply

About Me

I’m Sunjeet Khokhar

An experienced People Leader,Practice Lead and Test Manager .

I am driven by the success of people around me, am a keen student of organisational behaviour and firmly believe that we can be better craftspeople by being better humans first.