People who have started their careers and are working in automation usually have a question in mind what to automate and what not to automate.
This is a very big question, especially when it is UI tests.
Understand the difference of Automation checking and Automation in Testing.
UI Tests are usually expensive and require many resources compared to Unit, API, or integration tests at the code level.
I would like to share my experience about what should be automated and what should not be automated.
Before we talk about what should be automated let’s understand what should not be automated.
What should not be automated ?
- We do not automate most tasks whose testing can only be done in a client environment with the client’s internal data and resource/API that we do not have access to.
- In the era where Gen AI is evolving, where machines are trained to think like humans, we still do not automate the human creative thinking journey which includes thinking. Thinking about test scenarios, strategies, and planning we can assist the AI but we do not depend on them.
- User Interactive task on UI to measure the User Experience we do not prefer to have that automated.
- Unstable feature that keeps changing, we prefer to have some integration tests in place (like smoke tests) but we do not consider it in the scope of automating it till the time the feature becomes stable.
- Tasks that have too much complexity and too little ROI (Return on Investment).
- Features that are one-time activities to develop once and no change is required, either the source code to be given to the client and which won’t change further.
- Common features across multiple modules can be automated only once and should be avoided to be automated across all modules. I have spoken to many testers who now question whether common functionality has a common code base with developers and end up automating again and again which should be avoided.
- Less Risk-prone areas in the web application. You can do a risk analysis of the feature and then decide if it has less risk feature than we don’t.
What should be Automated ?
Automation things that make tester’s and developers’ life easier, understand the purpose. Automation is not ONLY about creating tests and running them but automation can be used to solve problems by helping tasks that can be automated and make life better.
People in teams and across will surely thank you for making their life easier it can be a simpler example which is very common in automating repeating tests.
Lets dive a bit deep in this,
- First, automate tasks that make life easier for testers as well as developers. The tasks that are done again and again. We have runners that run automation tests from GUI like a music player, Run Start, and Stop. An example of this can be a Test Case developed with the NUnit framework can use Test-Centric as a GUI runner.
- Commonly known test run again and again (Test cases that helps in re-testing and regression testing).
- Automate Test Data creation, this usually helps when you need to create a large amount of data or complex data that needs to be created again and again.
- Automate tasks done in the pipeline like running Unit and Integration tests with builds.
- Plan and run Smoke tests and different types of tests that are feasible in the pipeline automate and schedule them.
- Automated results, yes you heard it right we can have reports generated automatically and shared over emails after automated test runs.
- Automate monitoring and analysis tasks, like logging, and capturing videos, and screenshots. Any ways to gather information on application behaviors.
- You can even schedule performance tests to run in the pipeline.
- Resource consumption to run tests can be expensive, we can create an environment at run time, create an In Memory database (not preferred for UI tests), deploy the application, and then run all tests (usually done for Unit and Integration tests) and delete the entire environment.
- We can Automate Database restorations that can help to test with fresh data.
These are some of the things that I think can be automated and which should not be. The scope of the article can be much bigger and can have many more things.