Sunday, November 08, 2020

My journey of Software Testing - Looking 20 years back - Part 1

“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 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 ….


No comments: