In many QA Job opportunities and postings these days, I have
observed that almost 90% of the job descriptions specify coding and automation
knowledge as mandatory. This does seem natural, going by the logic that IT and
software companies do require a certain amount of computing cognizance. But as
a hard-core QA professional who’s spent more than 12 years trying to break code,
it really doesn’t make sense.
And why you ask? Surely a good tester should know how to
code? I beg to differ. While I agree that knowledge of coding is definitely an
advantage for a tester; a feather in one’s cap, it is no substitute for
hard-core testing and QA skills. It takes a fair bit of creativity, instinct
and effort to find critical bugs in software. In today’s highly complex
software scenario, testing has evolved into a highly specialized and viable
career option rather than an offshoot of development and coding which many
sadly perceive it to be even today. It is a mistake to ask your tester for
coding skills. If the testers start to code, then what will the coders do?
In the good old days of yore, software project teams were
split into specialized teams based on their job functions: BA teams for
requirement gathering and liaising with the client, A technical architect for
designing the software architecture, DBA teams for setting up and maintaining
the Database, Development teams for coding and unit testing, a QA team for
preparing Test cases, RTM and testing the application and an Application Maintenance team for
providing support after product Go-live. Each team had a manager for guidance. Each
team had their defined boundaries and everyone had a clear cut task and skill. The
work was well-defined and everyone was happy.
But the scenario is changing fast. Software is growing in
complexity day by day. The landscape has become very competitive, especially
for IT service providing companies based in India who look to add value to
their clients by delivering high quality software in a reasonably quick time. Newer
and more dynamic methods of Software delivery such as Agile have replaced
traditional software models. In a bid to maximize revenue, many companies
actually take testing very lightly and look to reduce the head count of the
testing team. In many teams, the developer to Tester ratio is highly skewed in
favour of the dev team. Many project and delivery managers sadly have a very
biased opinion about testing. “Testing?!! Mehhh ….. anybody can do that!” they
say. Very little priority and thought is given to testing these days and this
is the prime cause of software failures. When software fails, the credibility
of the organization and the team which built the software takes a hit and this
results in numerous other complications.
Which is why you need specialized testing teams for
detecting bugs before deploying the application and going live or before UAT. The
art and science of detecting defects in code is a very specialized skill which requires
a lot of patience, perseverance, skill, creativity, instinct and experience. No
amount of coding experience can substitute it.
Let’s take a simple example. Lets’ say you’re a newly
appointed chef in a reputed hotel and you have just rolled out a new signature
dish. You will of course, taste a bit of it to check if all the ingredients
have the right consistency. Too much sugar or too little salt, a dash of chilly
and pepper to boost the taste. If you’re satisfied, you can send the dish out
to the customer. But you would be taking a great risk in doing so. A wise and experienced
cook will always have the maturity to let a specialist taster and sampler to
sample the dish before sending it out. Let’s face it, we’re human. If we were
in the cook's place, given the time and effort we have spent in making the dish we will
tend to feel a bit biased towards it. Deep in our heart, we would like to
believe that our dish is perfect. This unfortunately, is an ideal scenario.
Something which is non-existent in the real world. Therefore, we would need
someone experienced, neutral and unbiased for tasting our dish. Someone who can
rightly detect any inherent flaws we might have inadvertently made in preparing
the dish. Someone who understands what cooking and good taste is all about and
also understands the customers’ needs. This would go a long way in ensuring
that your dish is well received. The flip side is: if your dish isn’t well received,
you can always blame the taster ... :)
The same is the case with Software Development. Software
Developers and Managers must realize that no matter how expert they are in
interpreting the requirements and coding and despite their best efforts, bugs
and critical errors inadvertently creep in. Some might be minor or cosmetic
issues, but some might be show stoppers and might ruin the software’s
performance, costing the company a huge amount of money to make a fix. Like I
said earlier, we’re only human. And developers do have the tendency to think
that their code is infallible. Every Software team needs a good amount of
specialized and experienced testers who can detect an inherent amount of bugs
in the application. Like the specialized tasters, testers (pardon the synonym) help
in reducing errors and improving software quality by making sure your software
product performs as per specifications and meets the end users’ requirements. As
I mentioned earlier this kind of testing is a full time job which requires
loads of patience, perseverance, meticulousness, creativity, a sharp eye for
defects and various other positive adjectives. Having a good knowledge of
coding makes you a good programmer but does not necessarily make you a good
tester. And of course; if things do go wrong in production … you always have
the QA team to blame …. :).
There are of course some areas where coding expertise is
required, such as Automation testing. But there again, a good record and play
tool eliminates the need for complex scripting. And as I mentioned in an earlier
blog post (
Manual V/s Automation), a good round of manual testing is required
before you can proceed for further testing such as Automation and performance.
So whether you like it or not, Dev guys; wake up and smell
the coffee. You will need testers to examine your code.
Asking your tester to code is like asking your number 11 batsman to
score a century each time he comes out to bat. When there are runs
required to be scored and wickets are few in hand, your batting skills
will come in handy. But that's not always applicable. You have
specialist batsman to do the job and if they have let you down then you
cannot blame the tail-enders for not scoring runs always. As in
software, each person in a team should have a core skill (batting,
bowing, wicket keeping) and he should stick to it and develop it well.
This is an open request to all IT companies, big or small to
let go of their obsession for testers with coding knowledge. This attitude has
made testing an endangered profession as it is. If this attitude persists the
day is not far off when testing and QA will be added to the extinct professions’
list. You ignore specialized testers at your own peril. In the long run, the
effects on Software Quality will be there for all to see.
