|
Importance of QA
Once a Talented programmer met someone with an idea and some money. In a short
time they built-up a team and started attracting other talented characters to help in the
development of their shared vision of whatever product they started with the whole
thing.
At some point, there realized, to have a QA support. Each with different perspective, the
money man is furiously looking for more money and the programmers are trying to put
the finishing touches on the product .On the other the sales is complaining that they will
not able to sell the realization of the dream until all these open issues get ironed out.
With realization of having a QA guy , where no one else knows or cares about the wider
world of process improvement and in fact there is no process here.Initially , the QA was
lucky there are some old notes somewhere that can be turned into a fantasy of what the
requirements were before reality set in and development actually started. If they do exist,
you will find that the requirements were compromised in meetings that happened
sometime in the dim past and the only current version exists in the minds of people who
may or may not still work there.
How do you attempt to bring Quality into such a situation? What exactly is it that you are
expected to do here? The job description is a perfect generic rehash of ones that you have
seen put out by a thousand other employers all of whom are in the same situation:
looking for the happily ever after.
For the last ten years Scott Ellern have been staff QA, consultant and contractor to the
some of the smallest and newest companies in the greater Los Angeles area. He had
spent some of that time working for the larger more established companies and found
“how it is supposed to be done,where realities in the world of smaller business are
different in the extreme from the ideals and the mandates of the larger companies.
Scott Ellern says Operating Expenditures are your salary and Capitol Expenditure is a
long running joke. How many times have I put together a test lab by asking questions
like Hey, is that paper weight an actual working hard drive?¯
Quality Assurance and testing can and does happen at this level. I have seen, many
times, departments get founded in this environment, thrive and grow into something
that my contemporaries envy. The trick is to take advantage of everything around you.
Make what you have work, and learn to overcome the absence of what is not there. First
develop a vision of what the QA department in this place should be. Take into account
the personalities of the individuals who are powering the company and make a plan on
how you are going to get to your ideal.
Once that is done, it will become your third priority. Once your plan is complete the
higher priority is putting out the fires of the moment. Unless your company is in a
regulated line of business, the top priority of the person who hired you is getting some
testing done and isolating the issues in module X that the programmers cannot or have
not been able to address.
Once your skill as a tester has overcome that issue, automate the tests that will prove the
issue corrected and put it into your regression suite. Wait a minute, you say there is no
automation tool available? You are living in the wrong world if you believe that.
Automation tools are all around us. You can find free and open source tools on the “net or
even make your own. Even Microsoft Office‚ has a built in IDE that you can leverage.
Perl, VB Script or whatever the programmers are using should also be available.
Open your eyes and your mind to get into the spirit of making things happen. In a small
business you have to swim harder or you will find yourself drowning in what you cannot
do. Remember the 80/20 rule: 80% of your problems are caused by 20% of your issues.
Find the one issue that accounts for most of the 80% and pursue it like your job depends
on it. It does. However if your mindset is that of a true tester and QA professional you
can address that one issue, and then go after the next.
In this environment you will have to own more than one job. You may find yourself
answering the support line, writing user manuals or even creating the requirements for
the next version of the software. Look at these tasks as the opportunities they are. You
can write requirements as they should be written, delete all the “should and make them
“must. The user manual can become a requirements document and / or a regression
script. The angry customer can become a stakeholder or even an outsourced tester if you
play it right.
All of this will make you and QA a valued and productive part of the business. You will
gain executive support and backing for your vision and perhaps even a little cap-ex. Even
with all of these potential gains, this is only the second priority.
The first priority and the thing that you must always be working toward must be putting
aside your prejudices and the cultivated adversarial relationship between QA and
development. They are your greatest source of information and your most convenient
means of getting your tasks defined and accomplished. Once the release goes out and the
customers hail your high quality product that accomplishes all their requirements the
developers will get the praise. Why because they deserve it. Your job is to make sure
they get it. If you can make that clear to the programmers, not only will they be happy to
work with you toward the common goal of creating great software that meets the
requirements but you will also get to share some of the glory that comes from a job well
done.¯
− Report by QAGUILD
posted on 15/12/2008 | 
