Classic Software Testing mistakes
– An introduction –
Have you ever heard the
expression “Been there, done that!”
Well…I have many times and when
it comes to mistakes the above expression can be at least bit annoying, don’t
you agree?
This is my point: We human beings
are prone to mistakes have the habit of inadequately communicating and in most
cases we are bad listeners as well.
Add the above flavors to the “Time
vs Budget” recipe and you end up with a tasteless “This is not what I ordered”
meal.
So what did go wrong?
Have you come across the “Quality
Triangle”?
Quality x Time x Money, if you
had to select 2 out of the 3 which would you pick?
Generally speaking, the “winners”
tend to be Time and Money. What about Quality you may ask? Well, that is
something that we will try to squeeze in with as little resources as possible
to execute as many tasks as possible within a time frame that is incorrect.
Furthermore, if you contemplate
the fact that the “Quality” element has been damaged it is plausible to assume
that the entire SDLC could be at risk.
So if you are a tester like me
you are probably saying…”been there, done that!”
When I look at the subject
“Testing Classic mistakes”, I usually but not always blame the budget
restrictions. If you as a company want to save some cash in the project you can
within other options 1. Start cutting corners and/ or 2. Reduce overhead costs
by hiring “Cheaper” labor. That in turn
could mean you have under skilled stuff.
Think about
this:
Testing is a skill, it won’t just pop up from somewhere! You need specific testers for a specific testing
effort. You need a unique mindset, attitude, approach, work frame and
methodologies that only testers can provide.
If not enough hard cash is made
available for a suitable Software Development Project (as every project will
have its own specific requirements), and as a consequence the project lacks the
stuff and skills, maybe it’s time to hold back for a while.
There is a great article about
this topic written by Donald Firesmith
at the LinkedIn website.
Obviously, budget restrictions
are not the only barrier when it comes to point the finger at the mistakes in
the SQA environment, of course not.
There are quite a few that we must consider:
“…Most of the
classic mistakes have seductive appeal, which is part of the reason they've
been made often enough to be considered classics. Do you need to rescue a
project that's behind schedule? Add more people. Do you want an earlier delivery date? Just set a more
aggressive schedule. Should you keep a key contributor who's
aggravating the rest of the team? Yes, the project is too important to let him go…” by Steve
McConnel.
I will broadly write and briefly describe a list of mistakes which I
think are at the core of the “Classic Mistakes” or as I like to call it “The
Immortals”, let’s have a look at them:
All the below examples will be better explained and analyzed on my next
article.
1.
Testing Tasks and
Responsibilities: A first major mistake people make is thinking that the testing team is responsible for
assuring quality. Remember this short sentence “ Finding bugs important to customers”
2.
Prepare your testing
effort correctly: test plans biased toward functional
testing – make sure to cover cross functional areas - Insufficient diversity
in test strategy -
3.
The work force: Make sure you
have the right people to the right job!
4.
Let’s crack!
Testers at work: Paying more
attention to running tests than to designing them together with poor
bug reporting are both classic mistakes.
5.
Test Automation: Attempting to
automate all tests is not always cost effective and correct!
Apart from the above specific SQA issues, I would like to add a few
more: (Why not?J)
6.
Bad-mannered Team
members: Failure to deal with such problem can undermine the morale and
motivation of the rest of the team and potentially increases stuff turnover,
product quality and productivity.
7.
Abandoning
planning under pressure: ran into schedule difficulties? Ditch the plane! I mean the plan! No mitigation plan means the
entire project is now in a chaotic state.
8.
Cutting corners:
Projects that are in a hurry try to cut out nonessential activities, such as analysis,
architecture, and design. From the Quality Assurance point of view the cuts
will be executed by eradicating reviews and test planning.
The Ax cutting effect: Cuts at the QA activities early in the project means extra QA hours at the end of it.
The question now is how much it will cost to get it fixed?
9.
Lack of Change
Control: How much of the software requirements can or probably will change
until release?
10.
Location and
infrastructure: Too many people! Broken chair? Hard to concentrate?
That’s it folks, I
hope you have enjoyed reading this article and looking forward to seeing you
again soon.
