Death of testing | Inspired by one of my respected seniors

Based on what one of my respected seniors “Harish Chander” started I am just adding my thoughts on it.

He as taken one of the burning topics in IT and nailed it well.

Here is what is started Is manual testing dead?

Though I am jumping in a bit late, however, I am on his side. Following is what I would like to add for the readers.

Testing itself is a broad-spectrum term, kills defects by identifying them however, this is never a ending process. Each type of testing focuses on a specific area, that other has not picked up or not focused thoroughly.

Let me explain it with few examples, unit testing is a way of validating the intent of a workable piece of code i.e. validating a method which can’t be done by any other form of testing, still it doesn’t validate, if the business goal has met or not or does this unit satisfy any of the requested feature (because a single method may or may not provide the requested features). On the other hand, if we just talk about manual and automation, being a human we tend to assume things and may miss on precision when the process is repeated several times, which would never the case with automated tests, no matter how many time you re-execute, similarly, being a machine automation can’t verify things like usability and something wherein the only intent is to test is the design should be soothing and attractive.

Having said that means that testing is never ending process and test managers or lead are to be intelligent enough to choose what is to be tested by what form of testing and how much of each form is required. Because any of these forms can’t test the 100%. This is where importance of test plan comes into the picture. In Agile same may be done by implementing the test policy based on your product.

The intent of testing is to remove defects because the the way I understand defect is a deviation from the requirement, even if you are trying to add “moment of truth” to a product by adding an awesome feature and this is not been agreed upon or the end user’s/client’s consent is not been taken it is a deviation/defect. For any such deviation it would be incorrect to say that the 100% testing was not done, however, you may say that testing was not enough.

Let me add another example for the code coverage wherein people try to achieve 100%, which is again not a feasible thing to do, 100% coverage means you are getting into those paths as well wherein you supposed that no one should reach, for an example a developer assumes and anticipate that what kind of exceptions could occur and handles all such scenarios with a meaningful message, however, rest of the exceptions are left unattended with a generic message like “Some has gone bad”, if your testing is reaching this, means you know when would this happen and this implies that a developer has to catch one more exception and has not done enough coding. And if the developer keeps on coding and tester will be able to reach this flow again this will become a never ending, probably.

Ultimately, you will lose business as someone else will win the game and cut the niche in the market and your product will not be accepted by the end users.

The crux is that any form of testing or code coverage can’t be 100% and should be supported by other form. Hence, be it automation or be it manual testing, there can be change it quantity and allocation however, there can be end for any of these.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.