What's big deal with testers? Hit that punching bag !!!!

 Once in every 1 or 2 years - testing team or function comes under "question". I have seen this consistently for last 20 years. For business leaders, Heads of Business verticals - testing has been a punching bag. Whenever leadership changes or sales go low or profits fall - suddenly discussion on "efficiency" and throughput per person becomes an important metric. Why do we need such a big testing team? why cannot developers do all the testing required? Why not end users do the testing required? why cannot be automate this stuff and get testing head count out of equation? Why cannot we do crowd sourcing? - are the questions that business leaders ask. Testing leads and managers - start running from pillar to post to justify why they exist -- come up with all sorts weird metrics and process maps to show why testing required. But business leaders are hell bent on cutting that "extra" fat in the system. There go "testing team " out of the company.

What is big deal about testing or testers ? They ask. First of all let us ask what is/ required to do testing? Knowledge of the system or business domain or technology that used to build it?  Let us explore...

Business analysts know the product inside out as they have "defined" it (by writing down BRD - business requirements document). They should be the ones best suited to do all or required testing. No?

Developers too claim that they know system inside out  - as they have created it. They know nuts and bolts of the system where each one is. Should they be the best ones to test the system?

End users are best to test the system as they are the ones that eventually use the system they know what should be there in the application. Are the the best party to test?

Before we respond to above possibilities - let us also look at how industries shaped the views about testing. In software world (or software enabled businesses), broadly there are 3 types of industries - Software product companies, IT services companies and IT organizations or captive units of other (non software) businesses - likes of banks or pharma or Automobiles etc. Each of these have a very specific and unique "culture" about software and hence about testing.

Software product companies call software development as "Engineering" and all activities about creating a software is put under one umbrella "software engineering". Testing is part of "engineering". Pre-agile Era had testing as part of "development" life cycle and developers did all testing that they could. Agile and Post Agile (now DevOps era) killed "testing" function or skill or requirement by few beliefs or practices. Agilists extend logic of all testing should be done by developers and said "quality" is every ones' responsibility. Thru practices like TDD and formalized unit testing - testing as seen as excercising or executing every line of code (they wrote). Testing would mean writing code - hence programming and testing at some point merged into one skill. If you are in an engineering team you did not do coding means - you are either a business analyst or project manager (or scrum master - not ring master !!! :) 

IT organizations  or captive units are next big communities - looked at testing as either some necessary evil or something that programmers or technologists should do. Business leaders of these groups saw entire software development as an alien thing and kept a safe distance from it. For these software or technology was a support function and thought any investment in activities (like testing) related to software development as "distraction" from their main business function. Technology teams in such organizations too had a strange problem or approach. They thought all required knowledge of business domain or application resides with business so technology job is sincerely translating whatever business gave as requirements. No questions asked. They also propagated a view that technology testing is a shallow happy path and basic validation. They believed its not their cup of tea to learn business domain.  So where did  bulk of testing go? To business and End users in the form of "User acceptance Testing".

IT services companies did not have any of such challenges about thinking about domain, business, technology and testing. They simply supplied what their clients wanted. Hence IT services companies had mix of both IT org and product company cultures. IT services companies did not have to have their testing culture. In the beginning (pre-2000) - by riding outsourcing wave - went and told their outsourcing bosses - "testing is low risk work - we can take it away and do it for very low cost". I have heard pricing models of testing services on unit basis - xx $$ per test case. How crazy was that? When they ran out of business supplying "low skilled" (almost brain dead) "executors" of test cases (called manual testers) - they started selling them as business analysts. In that parlance - business analysis did some testing but knew business domain and could "write" BRD's. Even today many testers think that "business analysts" are one notch above testers in terms of salary and org hierarchy.  That option too soon ran out. These companies then started selling failed or low skilled developers as "automation engineers". This going even today..... skilled testing has been dying... not dead yet.

I ask -- what is big deal about testing - what makes testing  "tick" in todays situation? Share your views.

 

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