Let's end all Testing related arguments for Good!
Introduction - The intent of this blog
Discussing various topics is always good as long as the discussion is done with good intent of increasing knowledge mutually. This blog doesn't intend to discard the benefits that we get when we discuss topics at all. The author rather intends to emphasize on the ground that such discussions should be done in a mutually beneficial manner. Yet, on various social media platforms, it's a general trend that discussions are triggered either to demean the original author or topics are started to demean other schools of thought or other ideologies. While it's perfect to live with our own beliefs, ideologies, principles and sense of perfection, this doesn't give anyone the right to not allow others to have their own set of those even if they are false (in one's opinion or factually). It's even harsh to demean someone for those sets of beliefs without knowing the proper background. There are lots of opinions, beliefs, partial facts, and experience records floating in the testing industry. At multiple times they contradict with one another and what I see often is there is often a discomfort when such contradictions are discussed. The reasons for such discomforts are not because either one is right or wrong but the overall general intent of persuading the other party. In my last blog about debates where I explained "Winning A Debate" is the least you can achieve out of it. This blog touches on various Testing Debates and arguments and how I see they are not benefiting the testing community in any form.
Some Popular Arguments
Just to give you the gist of it I am starting with some popular Arguments and Debates in the Testing Community.
There is nothing called manual testing
My Views
In General in the industry if humans are doing something for testing applications that can be very well done by machines it's called Manual Testing. You can call it Manual Checking, Manual Data Creation etc. But the intent of the word Manual focuses on the fact that Something is done by humans that can be also done by machines. Manual Testing is a very small part of the Testing process. Since it is part of testing, the term Manual and Testing were framed together to denote a part of Testing done manually by humans. Humans can do great things with a lot of analytical, reasoning and other abilities they have. Manual Testing denotes a specific part of testing that should be optimized by machines by leveraging programming and automation. Some things are not worth human efforts. Now we understand this simple background about the term Manual Testing there is so much discomfort and bashing you get when you use that word with people saying when we say Manual Testing we are not valuing human capabilities. But my overall experience is there are lot of Testers in our industry thyself are not valuing their human capabilities. I am talking about subset of this people who are doing just those things that can be mostly called Manual Testing, these subset of people miss on adding any value to the overall Testing process with all the human capabilities they have. The term Manual Tester is often used for Testers who do not use programming or automation to aid the Testing process. Although they might have been using a lot of their human abilities to add value to the Testing process which may even not be possible for machines to do. The tag Manual Tester for such Testers is demeaning in my opinion. So the problem isn't with the term "Manual Testing" but to whom we are calling "Manual Tester". I will still prefer calling people Manual Testers who are just doing things that can be done by machines and nothing more than that.
The Arguments
Keeping my views aside since those are formed from the beliefs acquired due to my background and experience. I will still approach anyone saying there is nothing called manual testing or whatever they claim with an open mind. Rather, I will be open to listening to their experiences around people, organizations and Testing altogether. But in this process, I or anyone will try to nullify their own beliefs with some reasoning. Just a claim, mantra, tagline or various attempts to prove by providing hypothetical metaphors are not going to help me nullify those.
How it's not helping anyone
To anyone outside of the Testing industry, this argument looks like just fighting for the right words. What matters is the intent of the commenter who says those words. I am still not sure what we will achieve out of giving proper names to proper things, and keep fighting words rather than intentions. Because in the overall process, with the flow we sometimes are unknowingly demeaning each other's experiences and beliefs. Moreover, we are diverting the core topics that are being expressed by a particular writer ( who as if did a crime by using these words )
There is nothing called automated tests, they are just automated checks
My Views
We are mixing the words Test and Testing. If we consider examples out side our industry for example in medicine doctors prescribe us a test which is mostly procedural. Where someone collects samples, do certain actions on those samples, records observation and produces them as report. Similarly suppose if you want to test presence of iron in soil by chemist. Chemist will collect the sample. Perform some procedures on those and record observation. What comes next after a test is called diagnosis ( or analyzing results ) and making conclusions. Test and Diagnosis are two different things. Then why in testing we want to mix a Test with Diagnosis or analysis which is part or overall testing but not Test. An automated Test also gives you similar procedural reports as good as reports provided by Test in other fields. What comes next to it is remaining part of Testing not Test. So in my views your automated tests are also tests if we define the word Test similar to other fields.
The Arguments
Keeping my opinion aside I would be still happy if someone can make attempt to define this terms in more generalized sense drawing similarities to other fields. The whole argument looks like straw-man fallacy where most of us understand all Testing ( which requires lot of human intelligence and efforts) cannot be automated but part of it which is Test can be automated.
How it's not helping anyone
To anyone outside of the Testing industry, this argument again looks like we are just fighting for the right words. What matters is retrospecting to what extent your Automated Tests add value to overall Testing process, weather you call them Checks or Tests doesn't matter. We should discuss more on how to improve automated tests rather what to call them.
We don't need specialized Testing role in team
My Views
Earlier some time back I made a post where I said If you require specialized Testing role in your team or not depends on what game you are playing. In basketball their is no goal keeper but in football their are goal keepers. Similarly Devs only small team where Quality Practices are mature enough and Devs are doing everything that would a specialized Testing role be doing then you simply don't need specialized testing role in those teams. This looks fantastic on paper but to achieve this nirvana state you really need to set up lot of Quality Engineering practices in your team, it doesn't come on day one but you can slowly progress towards that state. Its generally output of many retrospectives, coaching and Quality Consulting. But remember the premise, small teams, mature Quality practices and lot of Quality Consulting.
The Arguments
Most of the argument around both side try to focus on importance of particular persons skills, focus or dedication. But in reality all of the aspects required to achieve this or fail at this are both trainable and still can be error prone. The argument coming from mostly QAs that Testing and Quality are mindset but in reality they are different context as long as your skills, focus and dedication are aligned to different context and goals anyone can do it.
How it's not helping anyone
People come from different backgrounds and experiences. What worked in one specific setup may not work in another setup. Having Rigid stance at any of this two extreme poles can be harming the way you provide specialized solutions to specific context. Being open for both possibilities and taking call purely based on what may work in specific context is what have helped me throughout my career.
What we learn out of this debates
At one end I agree this debates are important to clear some misunderstandings overall entire industry has around Testing and Quality Assurance for software. But overdoing something equally harms it. I see right now whole Testing community is divided into two three school of thoughts. The overall interactions between them denotes so much heat towards each others rather than passion to for coming to same ground. This is harming overall Testing Profession. Lot of big names in this practices are just divided and not united.
What I seek as outcome
Being small fish in the ocean when I plucked all this chords of different debates I din't mean to demean any school of thoughts, rather I tried to show debating parties how I or any other common Tester would look at this debates. I rather mean peace in Testing community and want to see debates around and passion to solve Problems that we face while doing our craft. If any of those discussions are specifically talking about it then I am your audience, But if we are just talking about same things again and again its becoming boring to listen to same music everyday for me.