How to Decide What To Automate

When I started my career as a software system tester a decade past, automation testing was viewed with some skepticism. machine-controlled tests were exhausting to line up, long to run, and provided unreliable results. However since then vast advances are created, and currently the selection to not modify tests would be seen as very rash. I think this is due to the two changes in the software industry, the move to test closer to the code using unit tests and services tests, and second, the availability of more reliable test tools.

However, this doesn't mean that everything ought to be machine-controlled. Having too several tests are often a damage to software system development process. Tests that take too long to run bog down the feedback that developers get after they commit their code, and so bog down the complete development method.

And tests that are flaky or take an excessive amount of time to mend lead to a distrust of the tests, which suggests that they won’t be run in the slightest degree or that their results are going to be neglected.  

Therefore, the primary step in automation testing success is knowing what tests to modify and what to not automate. Here are some guidelines:

1. DO modify tasks as near the code as doable

Unit tests are therefore vital as a result of they exercise code practicality while not touching any dependency. If a developer makes a amendment that ends up in a hole in logic, that hole are going to be detected before the amendment makes it to the tester, saving everybody valuable time. a preferred trend these days is TDD, or test-driven development. this can be wherever the developer writes the unit tests before he or she writes the code, guaranteeing that they start by considering all the doable use cases for the software system before determination the technical challenges of writing the code.

Services checks also are very valuable as a result of they test the practicality of the software system while not rummaging the UI. several of today’s applications use Apis that build REST requests to the server. once rummaging the UI there are typically limitations to what a user will do, however once going directly through the API additional check cases are often dead. for instance, a UI would possibly limit the sort of characters which will be entered in a very kind field, however there might not be server-side validation on the input, that can be discovered through API testing.

2. DO modify repetitive tasks

Some tests are therefore vital that they have to run repeatedly. an ideal example of this can be the login test: if your users can’t log into the applying, you've got a true client service problem! however nobody needs to pay time manually work into an application once more and again. Automating your login tests ensures that authentication is tested with a large sort of users and accounts, each valid and invalid.

3. DO modify things users can do a day

What is the first operate of your software? what's the standard path that a user can take once victimization your software? These are the sorts of activities that ought to have machine-controlled tests. instead of running through a manual user path each morning, you'll be able to set your machine-controlled check to try and do it and you’ll be notified straight away if there's an issue.  

4. DO modify basic smoke-level tests

I like to consider smoke-level tests as tests of options that we might be very embarrassed by if they unsuccessful within the field. One company wherever I worked early in my career had a look feature that was broken for weeks, and nobody noticed  as a result of we tend to hadn’t run a check thereon. sadly, the bug was pushed dead set production and seen by customers. Automating these tests and running them with each build will facilitate catch major issues quickly.

5. DO modify things which will prevent time

A coworker of mine was checking a feature that required a very new account founded on every occasion the test was run. instead of set it up manually each time, he created automation that may founded a replacement account for him, saving him valuable time.

6. DO modify things which will enable you to exercise many completely different choices

A check that fills out a form by filling all told of the accessible fields isn't fully testing the shape. What if there's one missing field? What if there are 2 missing fields? What if one among those fields is required? With automation, you'll be able to exercise many various combos of kind submission in abundant less time than it'd desire do manually.

7. DO modify things which will warn you once one thing is wrong

I have many negative checks in my API test suites that verify that a user can’t do one thing after they don’t have permission to try and do it. Recently a number of those tests unsuccessful, alerting American state to the actual fact that somebody had modified the permission structure, and currently a user was ready to read content they shouldn’t.

8. DON’T modify tests that you just grasp are going to be flaky

If you can’t return up with how to run an automatic check on a feature and have it pass systematically, you will need to run that check manually or notice a unique thanks to assert your results. after I was 1st obtaining started with automation, I needed to check that a feature sent AN email which the e-mail was received. I discovered that email shoppers are difficult to check within the UI, as a result of there’s no approach of knowing however long it'll take before the e-mail is delivered. Instead, I verified that the e-mail supplier had sent the email, and infrequently did a manual check of the inbox to create certain that the e-mail arrived.

9. DON’T modify tests for options that are within the early stages and are expected to travel through several changes

It’s nice to put in writing unit tests for brand new code, that as mentioned on top of is typically done by the developer. And automatic services tests are often created before there's a UI for a replacement feature. However if you recognize that your API endpoints or your UI are going to be ever-changing quite a bit because the story progresses, you will need to carry off on services or UI automation till things have settled down a small amount.  For the instant, manual testing are going to be your best strategy.

10. DON’T modify tests for options that nobody cares regarding

Your application in all probability runs on a large sort of browsers, and your inclination is also to run your tests on all of them. however it can be that just one p.c of users are running your application on a specific browser. If that’s the case, why undergo the strain of attempting to run your tests on this browser? equally, if there's a feature in your application which will be deprecated shortly and just one p.c of your users are victimization it, some time would in all probability be higher spent automating another feature.