For those who don't know, an SDET is a Software Development Engineer in Test. Depending on where you work, that can mean different things. At my job, the role is about the automation of regression testing within QA. The primary purpose of this work is to make the lives of functional (manual) QA analysts easier, so they can do more exploratory testing work without having to worry about as many regression test cases.

Technically, my role is a mixed role, where I spend 75% of my time on automation work and 25% of my time on functional work. The reality is, being new, I've spent most of my first month as an SDET just getting onboarded and used to the team workflows so I can participate in automation activities with relative ease.

In this first month, I've learned a thing or two about how automation relates to functional testing, the ways it is more of the same, and the ways it differs from the day-to-day of a functional QA. I thought it'd be worth my time to share this information now before this first month starts to blur together with the months to come.

1. Communication is still important

As a functional QA, communication is important for a number of reasons. We don't want new bugs to go unfixed, old bugs to remain unfixed, teammates to be doing double work, environment issues to go unnoticed, etc. Basically, we don't want to negatively impact the software development process in any way, and this is all still true as an SDET. We have to say something if we see something that could be disruptive to others or the deliverability of the product.

As an SDET, there is the added concern that our code could cause conflicts for the team. Some ways this could happen:

• Git mishaps (merging old changes, merging breaking changes, etc.)
• 2 SDETs working in the same area of the codebase but with conflicting solutions
• Not keeping your project repos up-to-date with main and thus doing work that may not be needed

Long story short, staying in the loop only becomes more important as the number of responsibilities increases. SDETs still have the responsibility of reporting issues and performing regression testing, but they also have the task of making new tests to cover other areas of the application. Making sure everyone can work quickly without disrupting each other requires a lot of communication.

2. If you write code on a team, you need to know Git

It's something we hear all the time as self-directed community-taught developers. We're all told Git is important but unless we work on a team or just want to try out random Git commands for fun, when do we ever have a need for more than these:

• git init
• git add
• git commit
• git push

As solo developers working on personal projects, this is all you really need, unless you wanted to start making feature branches off of main.

On a team, everyone works on their own feature branches and regularly merges changes into the main branch of the project, so not knowing Git becomes pretty painful. Here are some examples of commands I use on a regular basis:

• git pull (get latest changes from the main branch)
• git checkout -b "" (make a new feature branch to fix a test failure)
• git merge main (merge main's latest changes into my feature branch)
• git push origin "" (create a pull request for my feature branch to be merged into main)

3. Developer onboarding is sometimes more challenging than the day-to-day work

When I was getting onboarded, setting up emulators and downloading project repos was often quite frustrating. Getting tests to run against secure repositories is a lot different from running tests on your personal GitHub repo. There are security measures in place to make sure that only authorized individuals can access the code, which makes sense, but can cause confusion if there isn't a lot of training documentation to work off of (or if that documentation misses your work setup's use case).

Aside from the security, just the complexity of dependencies and configuration created all sorts of vague build errors in XCode and the Terminal. Basically, the growing pains of a small team only a few months old. I still think it's worth mentioning, though, because onboarding is an aspect of developer jobs that often goes unmentioned, as it varies from company to company. Working for a startup company/new team has unique challenges that are exciting to tackle.

4. Other people will usually have comments about your code

This is worth mentioning because many people learning to code will tend to care more about if their code works or if it fits their chosen stylistic approach. We don't really have a lot of input from other developers when we're learning solo, so it can be a rude awakening when you get several comments on a PR that you thought was "perfect" "on your machine."

The key here is to treat all of this feedback as free educational material. It's highly valuable to receive regular input on your programming choices, especially if the feedback comes from experienced developers who've seen and done a thing or two. Development is more complex than just DRY or SOLID, or making sure you have clean code (whatever that means), or just making the feature work. It's about making fine-tuned choices that fit the context of the problem so you make the "best" choice as a team.

A good mindset to have is you're "always a junior dev" because then you won't think you're done learning. We never are :)

5. "Victory loves preparation"

Okay, so this one isn't really something that came out of the actual first month of training, per se, but it is a reflection on it. I'm sure that if I had not spent a month or 2 on a Ruby course on CodeCademy and RSpec course on Udemy, my life would have been significantly more stressful this first month as an SDET.

What I mean to say here is that if you have a strong idea of where your next career move will be, and you know what skills are going to be required of you when you get there, take some time to consider the benefits of teaching yourself some of those skills before you start getting trained by others. It can save you a lot of growing pains, although certainly not all of them.

Just because learning is part of the job doesn't mean we can't spread that learning out a bit or do some of it in advance. Keeping your courseload light at any given moment can help you achieve a balanced emotional state as you grow in your career, but that means you have to be proactive. Do your homework so you can be ready for the class discussion, so to speak.