So when would you automate your software testing? I have no idea, without a doubt. However, I do have some questions you may take into account when you make the choice. Most of these questions possess a common theme, and that is "What is my ROI for automating this software test?"

So let us check 4 such common questions:

1. How complex is the scripting:

Whenever you spend some time to create an automated test, you unquestioningly reduce the time period, you might be utilizing to discover and log defects. That lost time is only going to pay back with time in case your test remains valid for some volume of test runs. Once you write the script the very first time, you provide it life. It lives, if you don't really need to change the script by any means, and also the response to the test carries on being valid. When the script carries a bug inside it, or even the system under test changes, or possibly a new Operating-system edition changes an assumption, or a new CPU comes to town and results from your test to be invalid, your script passed away; therefore, you must re-examine if you're planning to invest the time to fix it again.

Is the application feature under automation core/critical feature?

If you are planning to do regression testing of some business critical areas of the application, then it makes sense to use test automation there. For example, if you introduce  a security holes in your application in one, the build then that may cause some serious damage in company’s reputation. So maybe for your application security testing is a vital part. Doing that manually for each build would be time-consuming and costly in the long run. So we can use test automation in those areas.

Is the software test I am trying to do tedious and error prone?

Sometime the test is not business critical, but you are trying to do the same stuff which may cause human error. For example, you may need to generate 1000 pdf documents from the web pages. This is a lengthy job and using a human resource for such a job is a bad idea as the tester could have found some good defects at that time. Furthermore, it makes the tester really unhappy and consequently, non productive.

Is definitely the attribute I am attempting to automate undergoing a

large amount of changes?

A very important factor which will trigger script death almost quicker than everything else, is definitely the application changing. For this reason scripting towards the API,  is really a lot better than scripting the UI. Usually, the User interface changes much more frequently compared to API ever will. In either case, determine that the feature is totally new and going through plenty of change. In that situation, stay away from automating your tests across the feature until it has settled down. So it means toward the end of the application life cycle, which is when you're busiest searching for those show stopper bugs.) Also Once this script fails, how easy might it be for me to check out failure?

Investigation is undoubtedly by far the most time-consuming portion of test automation. Write your scripts so that they are atomic or very distinct as to what they test. Do not write test scripts running for Around 30 minutes, unless of course this is actually the specific goal of the script.

For further reading on this topic I suggest you to have a look into the

article

About the author: Raj is having 14 years of experience in Software Testing and QA. Being a test manager he loves to promote testing related ideas and best practices.