From Tedium to Triumph: My Journey to Becoming a Technical Tester

Written by Krys Catterall

It all started a year ago…

I was thinking to myself, I really want to stop repeating manual tests that take forever or are really tedious. I wanna be an SDET!

I had no idea how I would go about doing this, or getting started. So I looked to Dunelm Quality Chapter’s Mentorship programme, and found someone who would be willing to mentor me along my journey. I am lucky, I found an amazing mentor and we got along like a house on fire.

Where did we start? With JavaScript basics, we did a few sessions on arrays, loops, arrow functions (okay I still have trouble with those… it just doesn’t “click” for me). Then we started looking at the coding katas that are shared in our chapter, to see how I would approach them. Turns out, my 10 years in data analysis writing excel formulae has got my brain used to the pattern of what to do.

The struggle then was learning how to apply the JS syntax to my thoughts. We tried, we really did to get me to understand it, but something just wasn’t quite locking into place.

I remembered one of the software engineers on my team had actually done a course through Code First Girls and so I asked her what the course was like, what sorts of assignments they did etc. After getting a feel for what I was in store for, I applied for the Javascript Coding Kickstarter course, and got in!

Suddenly I had someone who had been trained to teach people like me. Who had tips and tricks for how to turn your excel knowledge into javascript fundamentals. It was amazing. I learnt so much in just 8 short sessions, and it really embedded the knowledge that my mentor had given me.

Then what? Now I have this knowledge how do I apply it to testing? Along came the SDET on my team, who showed me how the automation framework we were using works. I spent a few months in the background fiddling with how that worked, how I could modify an existing test. How locators worked.

I hear you shouting “But Krys, automation isn’t just writing the tests, it’s knowing when to write the tests, and when not to!” Yes, yes it is. As part of my own learning, I started to look at the existing tests in our repositories and was surprised at how many E2E and how few Integration tests there were and how many went over the same steps.

All this time, a lot of learn and share sessions were going on in the Quality Chapter. The most impactful for me was talking about the testing pyramid, and where integration tests fit. Back to my mentor I went (who ran that session) and asked, so how do I mock responses so I can make integration tests? End-to-End (E2E) tests are relatively simple, find a locator, write the syntax for “it should do/look like this” and voila!

Mocking responses on the other hand, so you aren’t testing all the integrations that aren’t relevant, and you can start your tests at exactly where you want to? Now that was tricky, and I’ll be honest, I still have a ways to go learning how to do this efficiently. Both my mentor and my team’s SDET helped me massively with this, and how the page object model works.

I got confused, if the SDETs know how the testing pyramid works, why is it like this? I realised it’s because there is no overarching owner of the respository and the E2E or smoke tests. So every team who works in the repo, has to write tests for their section. Well that’s not very efficient, so I clapped my hands together and created a new Guild to tackle this.

I’m not the most technical person, and I don’t have the skills to solve all the problems, but we do have the right people who can do this. By creating the guild, I created a space where not only Quality, but all other Tech Chapters could input into the changes that would make our testing solution less flaky, more robust and reduce duplication. I can contribute by being a co-ordinator of the group.

Great, so now I understand the how, what, why, when, and where of being an SDET. I’m eagerly looking forward to the next opportunity to step into an SDET role. I’m excited to apply my skills and contribute to my company’s success. Watch this space, as I’m ready and prepared for the challenge!