Testers and the Code They Write

I had a great conversation with David Giard on his show, Technology and Friends, the other week and he asked a question that I’ve been thinking about since. “Tell me about the code that’s in QA and testing” – I answered briefly in the podcast, but have been thinking more and more about what kind of things I’ve been writing over the years. Some (if not most) software engineers think of Quality Engineers/SDETs as writing just test automation – code that performs actions in the application under test (via UI, API, etc), and validate certain outcomes. But it’s way more than that! My quality engineering journey didn’t start with automated tests at all!

I remember in my first job as an Associate QA Analyst (while I was in school to get my BS of CS), I was given a task to update an awk script that helped us turn production data into usable test data without exposing customer information. I was chomping at the bit to write code, and enjoyed the challenge of learning both the schema for the data and awk scripting in general.

Also in that job (maybe moved up to QA Analyst at this point?), I was given ownership of an Excel template with a lot of VBA code in it – this was something the sales folks used, and there were some bugs that needed to be fixed. None of the engineers had time for it, so I volunteered. That was fun and interesting – I owned that for a few years, and added some new features as well. I think that was the last VBA I touched, for better or worse.

I was also given ownership of the test automation code that our sister team in Germany had written in C#. This code was full of comments in German, which really challenged my high school 1/2 semester of that language! This was your classic test automation.

In my next job, I wrote a LOT of Bash scripts. The product was a proprietary Linux OS cloud backup and restore application, and we tested the back- and front-ends of it (including the operating system itself). We needed to replicate large amounts of files on Linux and Windows file systems; we needed to cause corruption, test deduplication, and basic OS functions. I kind of miss hot-swapping drives in that server room, but I don’t miss the late nights/weekends!

The next job had a lot of automation written using QTP already. I’ll spare you my thoughts on the tools, but this was more of the typical QA Automation, and all frontend.

I then moved to a team where I was lucky enough to work on a project that let me pick the tooling, and I chose CodedUI (RIP). This was the first time where I was writing the framework and tests all together, and working with the engineers on my team to ensure the code was up to par and they could run the tests too. Again this was typical QA Automation, all in C#.

I moved to an architect role, and helped define strategies and frameworks using C# for the typical UI and API automation, and did a LOT of code reviews. When we had need of tools (analyzing JSON files, for instance), I jumped at the chance to code more. I tried out Docker for the first time in this role, and gave tools like SauceLabs a spin.

Later, in more of an SDET role, I wrote all kinds of code – the typical tests for the UI, as well as API tests, utilities/tools for the team, AWS Lambdas that performed actions and reported to us in Teams, and configuring CI/CD pipelines in code. I used C#, JavaScript, and the bane of my existence at the time, YAML. This role was super fun, as I worked with some of the best engineers of my career and got to work in all kinds of technologies and flex all kinds of skills.

When I moved over to Xbox, I didn’t get a lot of typical automation time. I did, however, get to go back to writing utilities and tools. There were JSONs that needed to be compared, and every time they were generated they’d be in a different order – so I whipped something together to alphabetize them and run comparisons/output results. I dipped my toes in some Power Automate/Azure Logic Apps as well, to run some processes (check on a build ticket, verify a few things in the build itself, and report in some Teams channels with action items, for instance). I also helped out a partner team with their typical test automation needs when I had the time.

My last position at Xbox was all about the typical automation, but from the perspective of evaluating the test framework, providing feedback, and implementing updates. That was a really cool different view on writing automation, and I really enjoyed it.

I’m sure there are more little utilities and odd scripts I wrote over the years that I don’t remember. Essentially, Quality Engineers/SDETs in all kinds of industries are writing code every day that doesn’t test an application; it’s code to support their testing, or their team, or just to make life easier for them. Even “manual testers” are writing code to help them get the job done (especially now with the help of AI). This is, as they call it, “automation in testing” (shout out to Richard Bradshaw and Mark Winteringham!) This code can sometimes go under the radar – it’s probably not checked in with the rest of the automation, and might live on the tester’s machine.

I’m not sure what the point of this whole post is, other than to share some memories and highlight the different things a Quality Engineer/SDET might write. Maybe it can spark some conversation on your team – what are you and your engineers (of all kinds) writing, what can be shared more broadly to help everyone, what can be adopted by more to gain efficiencies across the team, etc etc.

Sharing is caring!