“You seemed to have a good eye
and aptitude about find bugs in software. Why don’t you pursue a career in
Testing/QA? “said Premjit
my manager at i2 Technologies roughly about 20 years ago. As it turns out he
was damn right in assessing my special skill and interest for looking for bugs
in software. At that time – like many other peers I felt Premjit was trying to
put me down by asking me pick up a career in Testing/QA while I was aspiring to
be a software developer and create awesome applications. That time (true in
most of jobs even now), developer meant to write/design code while tester means
to “test” (use) those applications to find bugs. Honestly, I felt, it was a let-down
for me.
I reluctantly took full time
testing role (at that time, in software product companies, testing was a part
time job and everyone were called as software engineers). I have to admit that
it was decision born out of fear of losing job. But in retrospect – here I am
20 years later – celebrating that shift Premjit suggested me. Post that shift, initial
few years were bumpy, I kept looking at my developer friends and used to envy
them. In initial few years I took roles that are closer to development while my
full-time role was to test. I was software librarian for a new product development
- teaching and establishing software versioning and build management. It was
interesting as I could hear few developers appreciating my knowledge
development practices, IDE (Visual studio) know-how etc. Soon, testing
component of my job increased and I became moulded well into doing testing. I
went on investing in learning about testing deeper – I took a course (2-day
workshop) by T Ashok
of Stag Software – who happens to be my first guru on software testing. He
still continues to be a great friend, guide and mentor. I attended a testing
conference by STeP -in
in 2004 – got convinced that the career I took up indeed has good prospect –
looking at and hearing all those leaders from industry who were managing
testing teams. I was introduced to leaders like Srinivasan
Desikan – I still continues to be in touch with him. In another interesting
encounter in same year, in QAI conference, I meet Vipul Kochar
– good friend with whom I continue to share good collaboration on software testing
related initiatives in India. Vipul in his talk (in that QAI conference) on
exploratory testing – introduces me to the works of James Bach who still
continues to shape up my thinking and influences me about “fearless and think—for--yourself”
approach to testing. That’s I think happens
to be a major turning point in my career in testing. That QAI conference was a
unique experience as that was my first instance of speaking in a conference,
guess what!!! topic of my talk was “Agile
Testing – is history repeating itself”.
I also meet Krishna
Rajan in that conference who would 6 years later would give a job for me at
Barclays. So, in many ways 2004 was an eventful year for me.
In the mean time I made
transition in to IT services world and started learning more about testing by
reading through works of James Bach
and Cem Kaner. I then came to know about Context Driven Testing school of
testing. There used be a yahoo user group called “software testing” where
James, Cem and others from CDT were regular contributors.
I vividly recall a post (query –
actually) in that group where I expressed my doubts of testing as I saw during
that period – 2005. This interaction on that forum with James Bach as a clear
eye opener for me and would set me in quest of knowing and learning more about
testing in coming years.
Here, I share few snippets of my
questions and answers by James. Read carefully. This is how a newbie tester
starts off.
My first question about testing
was about role of Domain expertise. Major view at that time around me (it is
even now largely persisting) was for doing good testing and excel in that one needs
to be a domain expert.
I ask “In testing domain
expertise is important - for example without knowledge of stock markets – you cannot
test an application that is meant for stock markets. I agree with this notion
but banking only on this is recipe for failure.”
James responded to this – “Someone
without specialized domain expertise can contribute to a test
project within any domain. Besides, some domains aren't that challenging to pick
up, and in some cases, the test oracles aren't that difficult. However, trying to test, say, a radiology
imaging system using only testers who have no knowledge of radiology would seem
dangerous to me.”
That as an important lesson to me
– while having domain knowledge in area application is a good thing but that is
not a mandatory thing. You can contribute to testing by various other skills in
spite of being a newbie in that business domain.
My next question was [paraphrase]
“Any developer can do testing (he/she does any way unit testing and other
forms of developer testing). So, if we train him/her on automation tools - we
are ready for state-of-the-art Testing. Why we need a separate role for
testing?”
James responded – “Any developer
can do testing. So can any plumber, any housewife, or any politician. Anyone at
all can do testing. Do they do it well? That's the question. Developers bring certain
skills to testing that I like to have in my test group. They also bring certain
biases.”
This taught me why it is
important just not do testing but doing it well – like a specialist would do.
Anyone can do testing – that is a fundamental human trait to check things. But a
professional tester would do testing “well”.
Developer Testing has its own biases. I was introduced to the idea of
what developers often miss when they test – conformance oriented or
confirmation heavy testing. When you are
a professional tester – you would look at the task of testing as if your whole
world depends upon how well you do it. It’s no longer a ‘task” that had to be
done. This thought made a huge impact on my thought process of testing.
I, then asked about another
popular field of QA Process” – Why certain companies bank on quality jargons
- CMM, ISO, Six Sigma saying that testing and QA are one and the same. Further they
claim they follow CMM /ISO/Six sigma based so quality is obvious outcome – we don’t
consider testing as specialized skill. We are fine with our developers doing
all required testing.
James dismissed this by saying
“Well, that's just corporate religion. I'm frustrated with that, too.”
This was a burning question that
I had at that time “As mentioned in points 1, 2 above, if we have developer who
can do testing with automation
tools and business experts who bring the
necessary business knowledge and speed/efficiency in testing - where is the
scope for Tester - How do I emphasise/sell
the concept of " testing"
being a unique software life cycle
activity and brings definite value to end product. In other words, in what
way a tester is different (in skill sets and nature of work) than developers
and business consultants or analysts? What is the need for hiring testers instead of
developers doing testing too?”
James responds – “I think if
you don't have a clear idea, yourself, about what testers do and what skills
they have, you won't be able to convince anyone else. Here's one skill: the
skill of making models. This is a sub-skill, in my reckoning, of general
systems thinking. Another skill is critical thinking, which involves using
logic, of course, including the process of abductive inference. These skills
are difficult to evaluate in an interview. Hiring people who aren't developers
is worthwhile for a few reasons: there's more people to choose from, they
probably have different biases, they won't be trying to get into a programming
job, they will probably be better at testing overall and they will become
better testers over time. I like hiring people with a philosophy education,
when I can find them. You have to *demonstrate* the value of testing culture,
in order to sell testing culture. Read
the articles and class materials on my website. Go to www.testingeducation.org and
take the BBST online testing class. “
I learnt through this response
from James that – I did not have clear idea of what good testing was myself. I
was just observing industry trends, what I hear in conferences and what my peers
speak about testing. I was also constantly distracted by “jobs” that are
related to testing but not testing actually.
Looking back, I laugh at myself
and raw thinking. But these interactions would lay good foundation for my future
learning. My continued asking about my
doubts about testing with likes of James and others Context Driven testing
community in coming years would make be a better tester and would put me in a
position that I can answer questions like these to myself.
To be continued ….
