How many (what percentage of) test cases do you automate?

“How many (what percentage of) test cases do you automate?”. It is a quite common question raised from the managers. But answering this question is very difficult. Because it is the wrong question.

If this a wrong question means, If this a wrong question means, What is the purpose of this question? What information, managers want to know from us? Probably to get some information about the progress of an automation effort, usually when automation is getting started. This is not unreasonable, but this question is not the right one to ask because it is based on a number of erroneous assumptions:

“What percentage of tests” implies that all existing tests are candidates for automation, and the percentage will measure progress towards the “ideal” goal of 100%.

It assumes that there is a single set of tests and that some of them are manual and some are automated. Usually, this question actually means “What percentage of our existing manual tests are automated?”

But your existing manual tests are not all good candidates for automation – certainly, some manual tests can and should be automated, but not all of them!

Examples: if you could automate “captcha”, then the “captcha” isn’t working, as it’s supposed to tell the difference between a human and a computer. “Do these colors look nice?” or “Is this exactly what a real user would do”? And tests that take too long to automate such as tests that are not run very often or those that. are complex to automate.

“What percentage of tests” also implies that the only tests worth automating are existing manual tests, but this is also incorrect. There are many things that can be done using tools that are impossible or infeasible to do when testing manually.

Examples: additional verification or validation of screen objects – are they in the correct state? When testing manually, you can see what is on the screen, but you may not know its state or whether the state is displaying correctly.

Tests using random inputs and heuristic oracles, which can be generated in large volume and checked automatically.

 “What percentage of tests” also assumes that a manual test and an automated test are the same - but they are not. A manual test consists of a set of directions for a human being to follow; it may be rather detailed, or it could be quite vague. A manual test is optimized for a human tester. When tests are executed manually, they may vary slightly each time, and this can be both an advantage (may find new bugs) and a disadvantage (inconsistent tests, not exactly repeated each time).

An automated test should be optimized for a computer to run. It should be structured according to good programming principles, with modular scripts that call other scripts. It shouldn’t be one script per test, but each test should use many scripts (most of them shared) and most scripts should be used in many tests. An automated test is executed in exactly the same way each time, and this can be an advantage (repeatability, consistency) and a disadvantage (won’t find new bugs).

A “what percent completed” measure is fine for an activity that is stable and “monotonic”, for example running sets of tests manually. But when you automate a test, especially at first, you need to put a lot of effort in initially to get the structure right, and the early automated tests can’t reuse anything because nothing has been built yet. Later automated tests can be written/constructed much more quickly than the earlier ones because there will (should) be a lot of reusable scripts that can just be incorporated into a new automated test. So if your goal is to have say 20 tests automated in 2 weeks, after one week you may only have automated only 5 of those tests, but the other 15 can easily be automated in week 2. So after week 1, you have automated 25% of the tests, but you have done 50% of the work.

Eventually, it should be easier and quicker to add a new automated test than to run that test manually, but it does take a lot of effort to get to that point.

This article is based on DOROTHY GRAHAM BLOG. This information was very useful to me while creating automation scope and strategy. I hope this information will help for your automation future. And my hearty thanks to Dorothy Graham mam.