The first (and most important) step on the road to a “Test Engineer”

In my "Ask me anything " meetings I often speak to testers/QAs at the beginning of their “test automation” journey. Some of them ask:

How do I become a “Test Automation Engineer”?

This article will help you to understand the “first steps” of this “Test Engineer” (or “SDET”) journey! What to do, how to do it, and when to stop and move to the next thing. ????

Let’s get started!

1 - Overview

If you look at the essence of the automated tests (or checks), they are programs! Programs are made from code. But it’s not “just/only code”! There’s more... There is quite a lot of “adjacent stuff” that is very much relevant to you. This information could be grouped into the following “knowledge baskets”:

• programming foundations (generic things like variables, data types, classes/methods/functions, loops/iterating, etc.)
• ecosystem-specific (running programs, accessing the filesystem/environment variables, adding external libraries, version control, etc.)
• framework-specific (using functionality provided by the test framework, for example, “cy.get(…).click()” in Cypress or “beforeEach(() => {})” in Mocha)
• testing type-specific (UI, API, visual, performance, accessibility. This will also influence the choice of the test framework)
• software under test-specific (web, mobile, and desktop will all have different tooling available)
• infrastructure-specific (CICD pipelines, running tests in the cloud, Docker, setting up test environments, etc.)

Be aware that this is not an exhaustive list! There is always MORE to learn (for example, see QA Roadmap here )!

The question goes:

WOAH! That's a lot of possible options, where do I start!?????

2 - Choosing where to start

A journey of a thousand miles starts with a single step. The fact that you are reading this means yours has already begun, you are making the first steps! ?? But what should be your next step?

The answer is straightforward:

Learn the foundations of programming and unit testing!

Why?

Often one of the only tools/frameworks a tester (or a QA) learns is something UI-related. Selenium/Cypress/Playwright. Initially, there is nothing wrong with doing it. The problem appears when you stop after learning JUST THAT FRAMEWORK. Many people do stop. Our subconscious brain tells us “We are done, let’s conserve energy” and we are like "Yup, sounds reasonable, let's chill!". And our brain is right, learning is hard and tiring!

But because of this, we, as a community of testing professionals, have the following situation:

Bunch of people produce bunch of semi-decent, semi-maintainable, semi-stable UI checks!

“When you only have a hammer, everything is a nail!”. When you only know the UI test automation, everything you automate goes via this interface. This is not ideal (I’m being politically correct here ??)!

For analogies, think about the building. Most buildings have a foundation. This is an absolute necessity if you want your building to last (or be big, or be strong). Otherwise, any storm could blow it away! Same with your “test automation knowledge”! ??

It is so MUCH EASIER to add “walls” and “floors” to a building (”more tests” to a framework, or different ”testing types”, or new “test frameworks/tools”) when you are confident that they are NOT GOING TO COLLAPSE on you! But where these foundations could be acquired?

3 - How to start

To be good at something you need to do it. Do it a few times. But if you are a beginner, you need a little help and guidance on where to start. Here’s what I recommend:

Solve programming challenges on https://www.codewars.com

1. Choose the programming language of your choice.
2. Choose the difficulty (start with “8 kyu” aka “easiest”).
3. Choose the subset of the language features that you want to learn.
4. ....
5. And then… DO IT! (to get PROFIT!)

You could write your code directly into a browser tab (although I recommend using IDE). And you can (and should) write your own unit tests. You can check your solution against a “predefined” set of test cases. And, when ready and confident, click the “ATTEMPT” button.

If you solved it correctly, aka “no bugs”??, you will get points! (gamification in action)

After you submit your solution, you will see what others did and compare “your code” to “their code”.

Don’t ever skip reading other people’s code!

Seriously, don’t skip! This is one of the MOST IMPORTANT factors in your learning journey. You will learn WAY FASTER and will not need to UNLEARN bad habits if you do that. Beware of the solutions upvoted like “Clever”! Clever is not always good. It is often a synonym for a "bad". Look more towards the “Best practice” solutions.

Good code is the code that can be read and understood by everyone in the team (especially by the junior developers)

4 - When to stop

You should never stop learning! You chose this life and it is forever ?? But in this specific scenario, for the PROGRAMMING FOUNDATIONS learning, this is your exit criteria:

1. ? You have solved at least a FEW DOZEN “level 8” katas (this is the name of the easiest difficulty challenge on Codewars) from the “Fundamentals” category
2. ? You have solved at least SEVERAL from each of the OTHER categories
3. ? When you read the description of the “level 7” (or even “level 6” kata) it doesn’t scare you and you think “I know how to do it shall I want to…”. Try actually solving them, they are more interesting!
4. ? You feel confident in your abilities and ready to move on (beware of the trap of the Dunning–Kruger effect)

At this point, you will be able to say "I know how to program!" So none of the typical tasks you face will not put you into a "blocked state". I'll give you an example:

You are hitting an API endpoint to "GET all customers". This endpoint response has an "array of objects" body. You KNOW (without googling) how to iterate this array to find an id of a person with a name "Ivan", save it, and use it in a subsequent HTTP request.

The end

Don't forget to boop that like button! ??

This helps the algorithm to show it to other people like you. The more people see and react => the more motivated I am to write more articles. I write more => YOU will benefit from reading it. ??

p.s. I coach people on test automation within the JavaScript ecosystem. UI/API/Unit/Performance/Contracts, you name it… You can book a free first consultation here: https://ivanandcode.com/coaching