Day to Day Activities of Automation Tester

As a tester who takes care of automation, there are various activities apart from writing code that a tester must perform. Here is a list.

I have done the below activities and still do most of them. 

1) Writing Script

2) Create a framework 

3) Maintain the framework

4) Giving estimates

5) Create utilities inside the framework

6) Analysing Reports for the Test Run

7) Taking care of pipeline

8) Understanding requirements and System

9) Deciding what to automate and what not to

10) Process Improvement

11) Performance improvement for the scripts

12) Bugs creation

13) Talking to stakeholders – BA/Dev/Customer/Developers

14) Sharing suggestions on how development can be improved

15) Creating documentation

Day to Day Activities of Automation Tester – In Detail

Writing Script

One of the primary responsibilities of the automation tester is to write scripts(code) to automate functionality. 

a) Some teams do the automation by converting test case to automated scripts. So here we have 1 to 1 mapping. 

b) Some teams do it at story level. So per story there could be one or multiple automated scripts. They might choose to combine test cases or avoid some negative cases. So 1 story can have 2 automated scripts and 5 test cases. 

c) Some teams do at scenario level. Here we can use the existing cases and modify them and don’t create new cases unless absolutely required. Here we have 1 to many mapping. 1 Automation script can map to multiple test cases. 

My personal favorite is option c) as it leads to minimum maintenance and automation at the scenario level and combining with b). A word of caution here is to not include everything in one scenario just in the name of fewer scenarios as it will make it too large and time consuming.

Creating a framework

You are supposed to create/use a framework to do automation. A framework can help you in the long run. The framework is a combination of things that make script writing easy. This makes sure you can focus on test part rather than rewriting the same code at multiple places like login/constants/utilities. It’s a way to stay organized.
Example – When you go to an airport, there are things in place that make your travel easier like check-in, security check, boarding, etc. So, it’s like a framework in place that makes traveling easier. Similarly, the framework is a supporting thing for your scripts.

Maintain the framework

If your project already has or you have created a framework, does not mean it’s over. Its maintenance is always an ongoing work. You might not do this on a daily basis but have plans for this to make your life easy. Check if your framework has support for parallelism, reporting, test data, and configuration. 

Example – Continuing the airport example, instead of people checking the ticket, we have scanners at some airports, which are like maintenance with little enhancement. 

With respect to automation, there could be some old library version which were long back updated. Bring them to the latest and test them fully so it does not break things. Like Selenium, TestNG, Cucumber, etc. upgrade them to use the latest features

Giving estimates

Just like for testing/development, in automation too we must give estimates and do sprint planning. What we are going to achieve in this sprint. How many cases/stories can be automated based on the capacity of the team considering holidays/number of people etc. So based on the complexity of the functionality, each story can have a task or multiple tasks for taking care of the automation with hours mentioned in it. 

Create utilities inside the framework

There are some common things that you must do in most of the projects. Following the DRY – Don’t Repeat Yourself principle, you can spend a one-time effort and make utilities that could be used by various tests

Example – Continuing the same airport example. You see at airport now we can check in with an app which has our data preloaded. So it saves time for security staff and you. So things are improving everywhere so your framework should be.

There are 2 main types of utilities.

Technical utilities

You can take them from one project to another without any major changes. These include reading configuration files, XML, JSON files. Getting date time in a particular time Adding subtracting date time. File operations (Creating/deleting files, etc), Email reading, Database reading, etc. Make them in such a way there are no business specific things in this.

Business utilities

Some calculation operations that happen in multiple places in the system. Like handling notifications or pop-up messages, whose structure remains the same just the message changes. This could be specific to your application 

Report Analysis

Once you run the pipeline or a scheduled run is over, a report HTML/pdf/JSON will get generated. This is the output of a pipeline or local run. As an automation analyst, you should be able to analyze the failures, your report should help you in getting to the failure quicker. This is a daily task to keep your pipeline green as you can apply fixes and improve the pass percentage and help team to take decisions faster. Your debugging skills can help a lot here.

Pipeline Creation / Maintenance 

It’s important that the automation that you develop should run often. This is made possible with the help of pipeline. So pipeline creation/maintenance is an important part of the roles and responsibilities. You need to make sure all of your tests are running in pipeline and optimize the run so it takes minimum time.

Tip: Even if you don’t have parallelism at your Test suite level which is a common case in many projects. You can optimize the running of cases by creating various stages that can run in parallel and each stage can have a unique tag(maybe author). Also, you should see if the cases that are passed are genuinely working and not merely a false positive.

Understanding requirements and System under test

You should not just rely on test cases but look at the requirements in the user story/work items. This will help you in understanding the user ask in a better way. Additionally, you can add some check points(assertions) which are not explicitly written in the test case. The more you know the better you can automate and at a better layer may be API rather than UI.

Deciding what to automate and what not to

An automation engineer should not be a tool to convert test cases to scripts. They should analyze the requirements and the test case and then make the decision if it’s worth automating them. It could be a negative case that might not need automation being of less priority. There is a minor change that can be included in the existing automated script without the need to create a new one. Or it might have already been covered elsewhere. With each script you are adding a maintenance part, so be careful and give your expert input in it.

Process improvement

You should keep on checking the process followed by the team, be it PR process, tagging of the test cases, User story etc. Do share suggestions on what can be improved and the processes which can be removed if they are no longer adding any value and people are following for the sake of following them. You can save a lot of time and stand out by doing this.

Performance improvement

You should keep on looking and noting down what’s making the scripts run slowly. Why pipeline is taking 4-5 hours to run? Why there are similar failures frequently? So do add work items in the backlog to address this problem. The performance of the framework can help in longer runs. Find out how you can avoid waits, and how you can make 1 call instead of many. 

Bugs creation

Whenever you are starting to write scripts, you may face problems, system might not be working. You should be able to analyze if the problems happening are bugs. Then you should be able to create bugs and not be dependent on someone else (Say dedicated testers) to create bugs. So this way you support the testers working on the testing part, by not putting your task of bug to someone else and you know system better

Talking to stakeholders

BA / Architect / Developers / Scrum Master / Customer – You should talk to the stakeholders in your team and share your findings/reports/automation dashboards occasionally to take their input as with these discussions you will find some things which are not required to be automated. Also they will bring their perspective and can save a lot of time for you.

Example – We were trying to automate the loading of data and it was taking 15 seconds to load. BA confirmed that customer will never have this much data which we had in our test account. So we saved a lot of time.

Creating Documentation 

It should be easy for someone looking at your code to understand. So its important to keep the documentation up to the date in wiki and readme file of your code.

I have tried to cover the things I do on daily basis. There are some other task like charging hours on the task, giving KT to new team members and taking interviews that would fall on our plate. Do let me know in case I missed to cover any which you are doing as part of your daily activities as a tester who automates.