#nothingcalledmanualtesting… What’s the fuss about?
Off late almost everyone in the testing world is talking about “Automation testing” or “Test automation” and someone with that prowess having knowledge of tools, expertise in coding is suddenly treated as demigod. The respect level goes up and there are comparisons with people who do not use tools or have knowledge of coding. There are significant differences in the the pay grade as well.I think that’s the first misconception and it’s time we need to get rid of it...
5 min readMay 30, 2020
There’s #nothingcalledmanualtesting.
As a matter of fact the term test Automation is also a misnomer to say the least. What we have is only testing. Use of code and tools and no use of code and tools are only ways to execute the checks so stop dividing Testing just on the basis of how you execute. And stop referring to yourselves as manual testers as there’s nothing like that... Call yourself a tester or test specialist in the area of your expertise...if your forte is UI testing, UX testing, API testing, Data Base Testing Security Testing, Performance Testing,Accessibility testing etc. Then you can call yourself correspondingly a UI test specialist, UX Test specialist, API test Specialist, Database Test Specialist, Performance Test Specialist, Security test Specialist, Accessibility Test specialist and so on. If you know tools and coding then call yourself a Selenium Test Specialist or Ranorex test specialist and so on... Or if you are an all-rounder, call yourself a Tester/Test Specialist/Test Expert and be proud of you... I have nearly 2 decades of experience in Testing and feel proud in calling myself a Tester.
If someone else calls you a manual tester... educate them and if they do not wish to learn, move on because it does not matter. If you have the knowledge of coding and tools... Fantastic!!! Use this knowledge and skill to increase your efficiency as a tester and focus on other areas that need to be tested. Remember -
Automation is a service to testing and not a replacement!
What we are probably talking about is just the way we execute our tests (i.e. so called manual and automation). So first of all there should not be any segregation of testers merely based on the way tests are executed) and people need to stop using the term manual testing and stop describing themselves as manual testers. Secondly we need to stop others using these terms and educate them. It is ok to classify testers based on the types of testing but it is not ok to group them only by the way they are executed.
Now Let us talk about automation. In it’s current form automation is primarily converting existing tests( read checks) into a language that a machine can understand and run thereby reducing human intervention. This helps in testers gaining efficiency by letting the redundant tasks such as repetitive regression tests being handled by the machine and the tester becoming free to focus on other areas of the product that needs to be tested. So it is a myth that automation can actually replace testing... it can never happen.
Those who are campaigning vociferously for automation and its advantage do not realize that the code that is required for machines to run the tests is also written by someone... and will need to be constantly, analyzed, updated and maintained by someone (what people like to call manually). This code will alert you about any difference between the result and the expectation that would have to be analyzed further by an individual. This analysis may point you to a bug in the application or an anomaly in your automation script. Let’s not confuse between automation and autonomous... Autonomous is fully done by the machine and what we call as automation still needs to be designed, developed, maintained by human intervention (read manually).
Automation is not a magic wand and someone who can automate is not a magician. It is only a means of adding value to your testing by making you more efficient and productive. So stop treating automaton engineers as demigods. And automation engineers should not treat themselves as if they are from some other planet and are superior to others.
What also needs to be understood is the difference been a test and a check... a test is something that you do to investigate/evaluate the product and then carry out further analysis base on the decisions you make out of the feedback you get and check is something that you do is to validate/verify... So what you have termed as test cases are checks which you mark as pass or fail whereas the tests give you feedback and not pass/fail results... Only situations involving a pass fail output can be automated and not the ones with a more open feedback which may require further human interaction.
Checking is a part of testing but not testing itself.
In simpler words... A check has two possible results - Pass or Fail whereas a test may have multiple results - Pass/fail/high/low/needs further analysis/needs feature revamp etc.etc.
For example, If I am testing the tensile strength of wool and silk then at the end i will say silk has more tensile strength based compared to wool. Isn’t it? and that would be based on a series of experiments that I conduct.
Similarly, when you do Split Testing or A/B testing you don’t say A pas/ B Fail or something like that. Always remember
Testing is investigating/experimenting/exploring the product to find out risks and discover unknowns. Defects are only a byproduct of testing and checking the conformance to requirements is only a part of it . The purpose of testing is to provide valuable information backed by data to stakeholders so that they can take informed decisions about the product.
