Is Automation Testing a Good Career?

Do me THREE favors, Please! 

This post can be a dry and boring read especially for some target audience from Millennials and Gen – Z. I am yet to figure out how to automate learning boring stuff in a similar way that Al Sweigart could think of and get done! 🙂

Nevertheless, I humbly request you – the meticulous reader – to do THREE favors to me, PLEASE!.

1. Do not attempt to read this post in one sitting. It can be overwhelming and less valuable. Reading in one go is not impossible at all but it is not recommended. 
2. Read this post along with attempting periodic To-Dos to get optimal value out of this post. Afterall a career in automation consistently demands us to solve problems and bring value to the table in a context! 
3. Once you are done reading, share your learnings, Aha moments, constructive feedback, criticism and disagreements in the comments section.

What’s In This Post for You? 

The direction in which education starts a man will determine his future in life. – Plato

Now, Read below five paragraphs carefully to anticipate what may come your way in next sections and this entire post.

This post reflects my opinions based on my hands-on experiences above and beyond GUI automation. I am not in a position to give a Yes or No kind of binary answer to this question ‘Is Automation Testing a Good Career?’ I am not going to make any sensational or çheap remarks to attract undue attention. I am here to open the doors for you to make choices on your own based on your Interest, Attitude, Critical Thinking Skills, Ability to explore business value areas and Technical Skills. So, if you are still looking for a binary answer, this post may not be so interesting for you.

At the same time if you are a curious, open-minded and a serious learner and if you are still reading these lines then it gives me hope. I hope that I am in the right company of a student who is curious to know what can be better than a ready-made Yes/No answer. If this way of learning works for you, continue reading.

I offer to share – as an employee – my hands-on experiences in Automation in Testing. The experiences from serious automation endeavors, their successes and often failures, anecdotes and learnings from them. I offer to share these experiences hoping that you are naturally intelligent enough to choose or not to choose to kick off your journey of ‘Automation in Testing’. 

But wait! Did I say “Automation in Testing” instead of “Automation Testing”? Yes, you re-read it right. So, with this change, the question becomes ‘Is Automation in Testing a Good Career?’ Please allow me to take this for granted that you accepted this unwanted change and my response will revolve around this new question. 

I respect that others may disagree on how I conclude answering the question ‘Is Automation in Testing a Good Career?’. A healthy debate and constructive feedback are always welcome if such disagreement of any degree occurs. 

But before we begin and As I almost always do, let me first pay!

Gratitude 

If I have seen further than others, it is by standing upon the shoulders of giants. – Isaac Newton

I am grateful to some of my smarter, better skilled and deeply hands-on ex-colleagues and seniors in the space of test automation and testing. They are amazingly skilled, focused, dedicated and productive. They are capable of identifying, understanding and bringing business value(s) of Automation and Testing on the table. Working with them helped me understand that…

1. It doesn’t pay well – in the long run – to stick to GUI (Front End) automation only. Think better, and beyond GUI.
2. There are plenty of opportunities to exploit, allowing good testers and automation engineers to solve better problems and build their credibility and reputation. 

Let’s now talk a bit about Automation before we get further into the Career question.

Automation?

“When I use a word,’ Humpty Dumpty’ said in rather a scornful tone, ‘it means just what I choose it to mean — neither more nor less.’

‘The question is,’ said Alice, ‘whether you can make words mean so many different things.’

‘The question is,’ said Humpty Dumpty, ‘which is to be master — that’s all.”

― Lewis Carroll, Through the Looking Glass

For this entire post whenever I will use the word Automation, please understand that I mean to say,

• Automation in general and in any walk of life 
  • Something that makes my day to day personal and professional life easier than before.
  • Something that helps free my time and helps me use my energy in doing other purposeful work that I think I should focus on.
• Automation in Testing 
  • Especially in non-AI driven SDLC (Software Development Life Cycle), I consider Automation as a trustworthy companion to human testing. It helps me conclude testing – most of the time – efficiently and confidently. 
  • As an essential outcome of test automation, I usually get the data which complements the data resulting from human testing. I then analyze and interpret the data to do risk management to help myself and stakeholders in decision making.

There is no doubt in my mind and I hope neither should be in yours – the reader – that automation is powerful and helpful as long as the following necessary but not that sufficient conditions are met,

• It is done thoughtfully, in the given context(s) and to solve a problem.
• It is continuously optimized, scaled and maintained well.
• It gets the attention and care that it deserves.

Automation of different types for different purposes at different levels and layers should be used as a highly reliable companion of a good tester throughout SDLC (Software Development Life Cycle) and within TCs (Testing Cycles).

What’s your meaning(s) of Automation? How does that meaning differ from what I just described above?

Let’s look into how I see the act of automation!

To Automate is to?

“It is not enough to do your best, you must know what to do, and then do your best.” ― W. Edwards Deming

This post is not about Code, Framework, Best Practices, or Tools. This post is about building awareness, uplifting thinking and enabling some of you in making career choices afterwards. In my opinion a good automation engineer – as she gets mature – keeps on thinking on these lines. 

• To Automate is to Serve a Purpose.
• To Automate is to Solve the Problem(s).
• To Automate is to Bring Value(s) on the Table(s).
• To Automate is to Serve the Business, Departments and Functions.
• To Automate is to choose from various Processes, Interfaces & Tasks. 
• To Automate is to First Think Critically and then Program and Code Professionally.

The order is not strict as everyone’s job functions may be different at various experience levels. What matters is ‘Awareness’!

To-Dos from here

Tell me and I forget. Teach me and I remember. Involve me and I learn. – Benjamin Franklin

Nor am I here to deliver a monologue and I am hoping neither of you are interested in such dead communication. Hence, I propose to learn from each other as another outcome from this post. For almost all sections from here and especially for a serious learner, there are a few To-Dos

1. Take a Pause after reading the details in the upcoming sections and reflect on what is said.
2. Give yourself a Break and Re-read (Only if required). 
3. Find out and note down for your reference and for giving me specific feedback w.r.t. What makes sense to you and what doesn’t and why?
4. Co-relate with your own experience(s), if applicable.
5. Pen down what comes to your mind before you move on to the next section. Think of what different would you say and why so?

So, the question is – Is Automation in Testing a good career?

Small aim is a crime; have great aim. – A. P. J. Abdul Kalam

Let me ask you – the reader – in what context are you looking for answer(s) for this question? Where are you coming from and what is the goal?

1. Starting?  Kicking off a career in Automation and more specifically in Test Automation?
2. Re-Starting? Paused for some time and now planning to come back?
3. Specializing? Becoming an Automation specialist?
4. Transitioning? Crawling, Walking or Jumping from ‘Manual’ Testing to Automation?
5. Concerned about Job Security? Organisation’s increased focus on Low-Code / No-Code automation?
6. Fears about Survival? Rumors of decline of code writers in the ‘Evolving Era’ of AI and GenAI and LLMs?
7. Just Like That – In general?
8. Surveying?
9. Training LLMs for GenAI purposes?
10. What else?

Find your ‘WHY’ first before you move on and before I speak on my eligibility to utter a single word on the topic. 

Responding to ‘Why’ should help you in interpreting and understanding what is coming your way in the rest of the post. 

My Experiences of Automation In & Around Testing

There’s no sense in being precise when you don’t even know what you’re talking about. – John von Neumann

As a ‘Manual’ Tester

This experience is in the context of web application testing when I was working with a team who was doing a POC (Proof of Concept) on automating a test scenario. I was – then – so-called ‘manual’ tester on a team. I was testing a scenario where a valid user,

1. When accesses a web application’s home page
2. And Logs in using valid credentials 
3. Then a designated landing page shows up
4. Then User Navigates to and views a handful of other web pages 
5. And the user then finally Logs out.

Quite a familiar and simple test scenario, right? Probably not back then in 2007 I guess based on how I perceived it.

As I was inquiring for automation POC status to my peers in Test Automation, below was a response based on newly created script execution results!

स्क्रिप्ट फट रही है, लगता है पेज एलिमेंट्स में कुछ न कुछ चेंज होता है रात वाली बिल्ड में और हमें बताया नहीं जाता। 

“Script failed to execute successfully. It seems that Page elements often get changed in the nightly build and we are not duly informed.”

And this was – as far as I can recall clearly – my first experience with Web Page GUI Automation. Since I was brand new back then in 2007, I was surprised to hear and thought ‘Oh My God! This is something bad’. 

Today after seventeen years of hearing that ‘Element changed story’ – almost everywhere – I am neither surprised nor concerned about such a reaction. 

No doubt that definitely the things have improved over time e.g. 

1. Web development technologies have evolved. 
2. Automation tooling and frameworks have evolved.
3. Self-Healing mechanisms showed up including AI enabled ones.
4. Web element identification prioritization has been published over and over and over.
5. Automation designers started applying fallback techniques for element identification in their frameworks.
6. Automation engineers now seem to know what works best.

But I still see similar concerns popping up in Front End Automation e.g. Flakiness of Tests – the way it is prescribed – is a problem which is being addressed these days. Nevertheless, this all makes a different topic to cover some other day in the context of ‘Front End Automation’. 

What I learned was about the day-to-day challenges in the life of an automation engineer when it comes to front end automation. Especially when you are in an early stage Agile setup and have unreasonable expectations and promised delivery of In-Sprint automation!

As an Automation POC Engineer

This time the pockets of the organization were deeper as compared to the previous one! The context of automation was POC (Proof of Concepts) to begin with. 

But this time I was responsible for doing that POC using QTP (Quick Test Professional), AutoIt and VBScript for a VB.NET, Windows Forms and SharePoint technologies based legacy back office financial application. This time I and my colleagues were well aware of,

1. Element identification related issues especially in the context of legacy hybrid apps.
2. Possible issues with this new tool QTP e.g. Script Replay failures.
3. Cost and Benefits of this effort.
4. Departmental value if the POC gets successful and we get approval to purchase a license and kick off full-fledged automation efforts.
5. Chances of failures and management’s response if that is the case resulting in another POC?

The POC went quite well from a product coverage standpoint but we missed the deadlines at least twice and this ‘missing deadlines’ eventually went against us. 

On our failures to meet deadlines and crossing allocated budgets, one of the key phrases uttered by one of the most senior guys in the department was.

संदीप, ऑटोमेशन लक्ज़री है जरूरत नहीं है. ये जो सब किया है टूल से इसको मैन्युअली भी किया जा सकता है, थोड़ा टाइम ज्यादा लगेगा बस. ऑटोमेशन में पैसा भी ज्यादा लगेगा और टाइम भी.

‘Sandeep, Automation is a Luxury, not a necessity. Whatever you did through Automation can be done manually as well. It may take a little more time but automation takes the extra money and time both’

Regardless of this specific failure to meet timelines and budgets, we were successful in proof of concept which later helped in full-fledged automation efforts. I still talk to people who are now on UFT and the automation suite is running well!

I learned VBScript, AutoIt, ASP.Net coding in bits and pieces. Thanks to Tarun Lalwani for his books on QTP.

As a Product Subject Matter Expert

It was totally headless automation in the context of writing complex macros in excel. The automation goal was to transform the product knowledge and build a non-commercial loan EMI generation engine in MS Excel. 

The idea was to further test that excel based engine against a proprietary software in which we didn’t have any insights. If our results from comparison were more precise than that of proprietary one, then we could promote, market and sell our engine to the customers as a more Reliable, Robust and Trustworthy Test Oracle. 

I provided my services as a product (not domain) expert. I first developed a hard coded engine which was later turned into a fully dynamic and user’s inputs based.

I would qualify that one – so far – as the most challenging and satisfying learning experience. We sold that engine to multiple customers and brought money to the table.

I learned VBA and stakeholders expectations management during this process.

As a Customized Test Framework Consumer & Reviewer

After my first encounters – indirect and direct – I was hardly infatuated with Automation. I was more of a ‘What if’ kind of tester checking and exploring software under test. For good or bad, I couldn’t appreciate web automation much until I joined an organization where Automation was an integral part of Testing. 

They were building an enterprise level – using those traditional terminologies Keyword driven and data driven – automation frameworks. I used those frameworks, I provided feedback and I often sat with the framework development team to see what’s inside, and what can be improved and enhanced.

I learned core Java, XML, PL/SQL, PICT, ACTS, Selenium, Selenium IDE and other tools during this endeavor.

Nevertheless, these were my first indirect and direct encounters where I got acquainted with Automation in general, Automation in Testing and GUI Automation.

As an Automation Designer & Implementer

My latest experiences include: (but details are not in scope of this blog post).

• Designing an ETL Testing Framework 
• API testing and Partial Automation using Postman
• Load Test Design and Execution using Apache JMeter

Let Us, further, Visualize Automation

By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest. – Confucius

I visualize Automation in general and Automation in Testing as, 

First – A Mindset which is developed and fine-tuned through Critical Thinking in Testing. 

• You must be thinking Why, What, When and Where of Automation. 
• You must be thinking of Context of Automation, Audience and Business value.

Second – A Technical and Technology oriented skill that can be learned.

Third – A Problem-Solving Activity.

Fourth – A helpful companion in detecting problems in software under test.

Fifth – A Habit of finding opportunities to Automate in the given contexts.

Lessons Learned in Software Testing applied to Automation

I am further enriching my visualization of Automation as a Mindset + Skill + Problem Solving + Augmentation + Habit, by drawing a parallel to my lessons learned in software testing as described below,

1. Test what is Ready to test, as soon as it is ready to test.
2. Test Early, Test Often and Test Enough.
3. Remember Velocity, Variety and Volume!

Let’s dissect the above three points one by one!

Test what is Ready to test, as soon as it is ready to test

I suggest to apply this lesson in Automation as

• Automate what should be Automated as soon as it is ready to Automate. 
  • This ‘’What is’ and ‘It’ is not necessarily a test. It could be any activity, task or process within the overall testing scope. 
• Automate at a layer and level where it suits the best in the context
• Automate by self or delegate to automate to the right person/group depending upon the layer, skills, and cost benefit analysis.

For example:

Workflow and Dataflow automation  

In one of the organizations I worked, the application was sufficiently ready allowing user inputs through GUI. The workflow under test spanned through three pages containing roughly twenty-five controls which were a mix of Text Boxes, Drop Down Lists, Radio options, Checkboxes and Buttons.  

I was overwhelmed by the work being done in navigating and manipulating the GUI controls. The way I saw one of my tasks in testing the workflow was to complete one workflow with one type of user and 

1. Initialize the workflow
2. Populate the database
3. Initialize the Request Queue
4. Simulate calls to mocked web services under the hood 
5. Push the application to a certain state (e.g. New to Pending)

I was supposed to do it for ten different types of users for twenty different types of combinations. I was not in Web Services testing by that time and didn’t have access to SOAP web services. 

Instead of waiting, after giving a thought to ECP, BVA, Combinations (Permutations were not applicable) and Integration among different fields and data values. I chose Selenium IDE to do this job. Got permission to use the IDE and did it. It saved me Time. 

I could run it repetitively. I could export the script and share with a team who can also benefit from that. It was Workflow and Dataflow automation with no intent to Automate a Test. It served the purpose!

You may want to call it Just in Time Automation, or an example of Shallow Automation, I leave that up-to you. For me and my team it solved a problem and made our life easier to focus on tests that were supposed to be executed leveraging the achieved state of application.

Test Design Automation

Later for the above problem, I chose PICT and early versions of ACTS (Thanks to Dr. Richard Kuhn for his generosity and support in giving access for a few days) for pairwise test generation. I further reduced the combinations by 

• Applying 80/20 principle
• Analyzing production data
• Discussing with business analysts 

Test Data Insertion bypassing GUI and API

Yes, for one client in the absence of GUI and API, I prepared SQL queries that could populate the database. My goal was to test the database for CRUD operation irrespective of Interface being used. Least expensive, fastest way to automate data insertion and Equally valuable learning DDL, DML skills on the go.

Test Case Generation Automation

Created a macro in an excel template provided and mandated by the organization for documenting the test cases. The tester responsible for that screen was supposed to enter only Web Page Name, Field Names, Desired Values and additional information on a different sheet of the same workbook. On a click of an event the Macro did its job. This helped us in dealing with some junior testers who usually go on estimating testing time by typing the same thing over and over and over.

Test Early, Test Often and Test Enough

We applied the above principle in Automation as follows

1. Automated checks and executed those to find out anomalies before pushing the builds to QA. We did this by building Smoke Tests suits on the top of automated unit tests. We kept in mind that there is least redundancy.
2. Automated checks and executed those to find out anomalies as soon as QA starts testing in lower environments. We did this by building Sanity Tests Suits.
3. Automate checks and execute those to evaluate overall Stability of the application in pre-production environments before we finally declare a build ready to push to production.

Note: We didn’t explicitly use terminologies like Shift Left, Continuous Testing etc. while doing all this. 

Velocity, Variety and Volume

If you recall the first point that I deliberately mentioned, I am of the strong opinion that critical thinking is the mother of all automatic thinking about ‘Shouldn’t we automate this piece of our overall testing problem because this activity(ies) are either…

• Mundane as well as Non-human judgment critical
• And/or Repetitive in Nature 
• And/or Demands Quick Execution
• And/or Diverse and Voluminous Data Driven
• And/or Demands Precision
• And/or Consumes a lot of Time
• And/or Strictly Business Process driven
• And/or Solving a combination of one or more above types of problems 

In a nutshell the above are some of the activities in day-to-day testing that really require human attention ONLY during conception, design, configuration and scheduling but not necessarily require human intervention at the time of execution.

Other good automation examples include Robotic Process automation which is not in the scope of this post but can be discussed later.

Journey continues but Some Truths that you should know!

If you have come so far and are wondering what it has to do with you, your question and curiosity at all, You may be right! 

What’s the fun in reading my story? Some of you might be tempted to say that we are not here to hear your story or self-proclaimed achievements and there is no reason to believe as we don’t see anything on your GitHub Repo, Your LinkedIn posts or your Blog w.r.t your Automation skills. So why trust you at all?

100% True that!

Truly Technically and Technologically speaking, I don’t really think I designed or operationalised any groundbreaking innovation in the Web / ETL / API / Load test automation framework. 

Of-course they were and are better in effectiveness, coverage and efficiency than the ones I encountered before but they didn’t get published for several reasons. BUT if you pause and remind yourself a bit on whatever I shared so far, most of my practical hands-on experience in automation came from,

Automation opportunities encashed

• User simulation of Front End of Web Applications
• Automating Legacy applications
• Automating Test Design (Pairwise Testing)
• Using Automation to build Test Oracles
• Using and improving Test Automation Frameworks 
• Designing and Implementing ETL and API Automation
• Designing and Conducting Load Testing (Web load simulation automation)

Roles I played

• Automation POC Engineer – Coding Automation
• Product SME – Delivering Subject Matter Expertise to Build Test Oracle
• Automation Tools User
• Customized Automation Framework Consumer and Reviewer
• Framework Designer, Implementer and Reviewer

These experiences – the way I see it – helped me a lot in visualizing, preaching, and practicing ‘Automation in Testing’ as a Craft!

Before we move on from here…

You can observe a lot by watching. – Yogi Berra

1. Have you got the gist?
2. Did you feel the soul of the entire post?
3. Did you intuitively if not intellectually get the key message?

I am hopeful that you did! I hope you understand that from a Thinking and Progressive Automation Engineer standpoint, ‘Automation in Testing’ indeed has huge potential as a career. 

1. Contexts keep changing and they WILL change.
2. Problems to solve keep changing and they WILL change.
3. Stakeholders expectations from YOU definitely WILL change.
4. We keep adapting and We WILL HAVE to CHANGE.

Chances of success are high for those 

1. Who are thoughtful.
2. Who will change themselves quickly. 
3. Who knows where to hit the Hammer. 
4. Who can visualize automating Left, Right and Center.
5. Who hunt for automation opportunities around and beyond GUI, API and Databases

There is no single iota of doubt in my mind that with AI, GPTs and LLMs, Automation opportunities, challenges and scope of growth shall evolve over time. 

Career: Opportunities, Prejudices & Challenges 

Nothing in life is to be feared, it is only to be understood. Now is the time to understand more, so that we may fear less. – Marie Curie

Opportunities

I would say there should be plenty of opportunities for Automation in Testing, BUT only for serious players either they are Absolute Beginners, Just Started, Have an intermediate level of experience or Highly Experienced. The opportunities and especially with the advent of DevOps, Shift Left, CI/CD, Robotic Process Automation and now AI-enabled or AI based software development. Testers who are technically strong, problem solver and good in communicating, 

Why – Purpose of Automation.

What – What to Automate and What NOT to automate.

When and Where – Where to Automate and Where NOT to Automate.

How – Techniques, Technology, and Skills.

shall be able to continue to see progress! Additionally, GPTs and LLMs are helping the solid practitioners – who are able to gain benefits from their extraordinary capabilities – of solving non-deterministic problems. GPTs and LLMs are also giving tough competition to automators who thought that writing a script was their monopoly. The new thinking and new ways to automate have to be adopted.

Prejudices 

These will not live longer now but still my job is to have you give attention to these prejudices. Don’t fall into these old traps!

• Automate Everything!
• Let’s solve all automation problems through automating at the GUI layer!
• Run behind the latest Automation Tech and Trends rather than understanding project and product context!

Challenges

Based on what I experienced there is already a shortage of automation engineers who understand the context fully, and are sufficiently skilled, technically strong plus who have a diverse experience of automation beyond GUI and popular tools e.g. Selenium, Postman. 

I have experience hiring, training and delegating automation to testers and almost in 60-70% of the cases I observed an immediate need of bringing critical thinking in asking questions and get on the top of 

• Why – Purpose of Automation.
• What – What to Automate and What NOT to automate.
• When and Where – Where to Automate and Where NOT to Automate.
• How – Technology, and Skills.

The other challenge – especially with slightly senior Automation Engineers – are their slowness in upskilling in terms of 

• Discussing and Identifying Business Goals of Automation
• Discussing and Identifying Stakeholders Goals of Automation
• Identifying key Audiences as in Business people, Leadership and Stakeholders 
• Understanding the language of Audience
• Understanding real business value(s) and KPIs

Start Investing in your career!

Don’t wait. The time will never be just right. – Napoleon Hill

I propose the serious automation craft pursuers (especially the beginners) to visit and revisit the fundamentals

Basics and Fundamentals

1. Testing – Study the book ‘Lessons Learned in Software Testing’ and read it like your Bible of Testing. Give attention to Chapter 5 – Automating Testing.
2. Automation – Study the book ‘The “A” Word’.
3. Test Automation – Study the work done by Rahul Verma, here.
4. Testability – Study this book and complement your learning with one of the most underrated pieces of the testing puzzle.
5. Learn from Others Experiences – Read the book ‘Experiences of Test Automation’ and relate to your experiences (if applicable).
6. Automate the Boring Stuff  – Read and Practice with this book.
7. Practice Programming a little deeper – Follow Sanjay Vyas and see if you are interested in taking his course from The Test Tribe.
8. Practice Automation at Interfaces – Follow Alan Richardson and see if you are interested in taking his courses on Automation.
9. Introduce Strength in your code – Read and work along Design Patterns.
10. Career – Act as you read the book ‘Skyrocket Your Career’.

These starting points – I strongly believe because it worked for me to a good extent – should help you gauge where you stand today and decide why, when, and how to move to the next step. Good Luck and don’t forget the 3rd favor! 

Feel free to post ANY of your questions in the comments box and I will be glad to respond.