The Regression Pressure

“Product release is one sprint ahead, we are in a hurry to complete the regression to ensure we are not delivering a broken product which could lose a customer’s believe on us and in turn effect business.”

Now the case is very similar in all the product releases in almost all the IT product companies who are committed to an on time Quality delivery which helps customer meet his own timelines.

Let’s bring the Pressure down with a story ( 0 point)

A group of managers were given the assignment of measuring the height of a flagpole. So they go out to the flagpole with ladders and tape measures and they’re struggling to get the correct measurement; dropping the tape measures and falling off the ladders.
A tester comes along and sees what they’re trying to do, walks over, pulls down the flagpole, lays it flat, measures it from end to end, gives the measurement to one of the managers and walks away.
After the tester is gone, one manager turns to another and laughs, “Isn’t that just like a tester? We’re looking for the height and he gives us the length.”

I leave the moral of the story to the reader. :-)

The Smart Way

Smart way of doing anything well is, doing well at core.

When it has to be performed:

A "final regression testing" is being done to validate the gold master builds and "Regression testing" being done to validate the product & failed test cases between system test cycles.

Once the majority of coding is completed (i.e., in the last planned Sprint), the manual regression test cycle starts. This is key since it helps to determine the stability of the application before it is pushed to preproduction deployment. Code and defect fixes continue during this phase, but this is to add value to the product.

Regression testing uses only one build for testing (if not it is strongly recommended). It is expected that all 100% of those test cases pass using the same build. Development should be on Freeze during this phase, if you expect and believe in Quality.

For any obvious reason regression testing could not be carried while development is in progress. OK, unless the feature being tested will have no impact with the current development it could be carried out.

What has to be ensured:

This ensures that "the same build of the product that was tested reaches the customer".

Selecting the test case for regression testing

Last minute bug fixes will have bigger impact of on product for being defective.Hence “selecting the test case for regression testing is really an art and not that easy”.

The selection of test cases for regression testing

1. Requires knowledge on the bug fixes and how it affect the system
2. Includes the area of frequent defects
3. Includes the area which has undergone many/recent code changes
4. Includes the area which is highly visible to the users
5. Includes the core features of the product which are mandatory requirements of the customer

Positive test case should be more focused than the negative test case at the time of regression testing.

 

The Truth

It’s always possible that a major bug fix may have minor side effect and minor fix result in a major side effect.

Effective planning can only lead to completion of regression on time.

How do I prioritize?

P1 : Sanity –Core features of the product.

P2 : Feature which drives more of your customer needs.

P3 : Area where most of the code change has happened and its integrated impact on the product.

P4 : Other features of low Priority and all other business functional units.

P5 : UI

Regression in today’s world is incomplete without having frequent test cases automated .

All automation should act like a good demon thread which should smoothly run in background.

The Co-ordination Dev Vs Tester

An urge to bind a developer who is carrying out new feature development, with a tester should be well synced. This helps a minimum of two eyes on the feature as well as test driven development which will lead to doing it first time right in the first iteration itself. Tester can carry out his regular activities as well as be in sync with the developer who is making changes, so that when the check in are made the test is carried out in a smooth and effective way.

Meetings and planning are core part of agile team, which means the more we communicate the more quality we deliver.

Laws 

Mosher's Law of Software Engineering:

Don't worry if it doesn't work right. If everything did, you'd be out of a job.

OK it’s for bringing down the regression pressure .:-)

Now you are telling me where do you find such laws ? There you GO : LAWS

                                    Thanks for reading :-) Hope you had a good time. :-)