“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.”
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
- Requires knowledge on the bug fixes and how it affect the system
- Includes the area of frequent defects
- Includes the area which has undergone many/recent code changes
- Includes the area which is highly visible to the users
- 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. :-)
No comments:
Post a Comment