It's been a minute...and a lot has changed

Well, it's been a minute since I blogged here. To be more exact, it's been almost 3 years.

In those 3 years, a lot has changed. I've grown in my career, from Test Specialist to Test Strategist to SDET to Engineering Manager. I'll touch briefly on what I spent my time doing in each of these roles.

Test Specialist

My time as a Test Specialist was as one on a team of 4 as part of an engineering team of less than 20 people. These were times of a rapidly growing team (and company!) who was trying to find their way into more modern agile development practices with shorter release cycles and more automated processes. The team was just ramping up on things like CI, unit testing, and more automated tooling and scripting.

After learning the product, I helped the team move away from documented test scripts and test cases to a more context-driven model. We worked to shorten time needed for testing by performing tests in more isolated builds and environments. I also had a large hand in standing up the first automated UI tests for the product. As the team continued to grow and we broke development down into smaller feature focused agile teams, I began to recognize a need for the testing across teams to share good patterns, lessons learned and work towards and larger goal of a quality product offering, not just individual quality products. 

This is when I proposed the role of Test Strategist...

Test Strategist

I spent the next 2.5 years at the company in this position. While I continue to be an individual contributor, I was also tasked with attempting to bring some order and consistency to the company's testing practices across the teams. During this time, I wore many hats where I performed manual functional testing for multiple teams, wrote automation scripts, designed and built automation frameworks and tools, acted as a release manager, and "unofficially" product managed the STS team's work (Software Tooling and Support - essentially our version of an automation and release operations team). I also mentored junior testers, provided coaching and direction on good unit testing practices, advised on quality metrics provided to Execs, and much, much more. In this time, the company grew from 2 feature focused agile teams to 8+ agile development teams - most of which having embedded functional testers, and all of which employing CI processes and incorporating some level of automated testing. 

6 months ago I left that role to move across the continent from Waterloo, Ontario to San Francisco, California...

SDET (Software Development Engineer in Test)

My official title here was "Software Engineer", but I was asked to focus first on building/improving the Windows UI Automation framework (since I had experience in such things - my last company's main offerings being primarily Windows Desktop based products). I quickly went to work not only implementing this, but also working to reorganize the way QA was performed and structured at the company (essentially putting my Strategist hat back on, in a way). My biggest regret in this time is creating the SDET role officially at the company. I now believe the correct approach was to just continue calling the role Software Engineer, but giving them automation specific tasks to work on (more on this on another blog post - OMG I have content worth sharing again...after my 3 year funk! *squeals with glee*).

A little context - our company is a cloud based offering, which allows customers to access their projects via web browser, iOS app, Android app or Windows Desktop clients. The means we have teams building features in 4 platforms, plus APIs, workers, services, databases and all the other fun stuff that comes along with large cloud-based offerings. 

My proposal was to move QA back under one "umbrella", with a QA Manager at the top. "Why?" you might ask. With most companies moving to embedding testers into agile, or "no specific role", feature based teams - the "QA Team" model seems obsolete. Well, a year ago I would have agreed with you. However, as it turns out, there are some issues with that. In our case, we had a consistency problem. Features implemented across multiple platforms were developed and tested in isolation from each other, essentially causing the platforms to feel like different products. On top of this, testers often lack direction and career growth when not exposed to a manager that actually knows how to manage them and help the grow in QA. The outcome of this are things like stagnant testing practices, and often a very high attrition rate - either losing testers to other companies, or to other roles within the company (this is not inherently a bad thing, as people should be able to move to various roles but ideally this isn't happening because people feel a lack of growth in their current role after a relatively short period of time).

Oh, by the way, testers are on the QA team as far as reporting and feeling like they belog to a team, but they are each given a feature set to own, and are embedded in the respective feature teams to be the testing lead on that team. There is no old school, traditional dev - test wall that work gets thrown over. We still follow the model of testers being involved as early as design and planning of features, through development, deployment and monitoring in production together with the rest of the development team that owns that feature.

Part of this move to a QA team was the establishment of SDETs, who build and maintain frameworks that the development teams can leverage for various levels of automated testing. They also help implement quality of life tools and other offering to help teams deliver products of higher quality at greater speed. That's always the goal, enable the teams to deliver faster without sacrificing quality. Arguably the SDETs could go either way with respect to reporting to the agile teams' engineering managers or the QA manager. We chose the latter. 

It was decided there should be a manager with strong automation knowledge for the SDET team...and thus my seemingly quick move to...

Engineering Manager (Platform Automation Team)

I now currently manage 2 SDETs plus a part-time contractor (long story, but it's working out wonderfully for us - hmmm, I smell even more blog content), and have positions open for at least two more SDETs. Besides the team management responsibilities, I still contribute to the building and maintenance of automation frameworks and CI tooling (though sometimes I look at the open instance of VS Code on my monitor, realize that it has been days since I typed anything into it and cry a little inside), as well as advise the QA team in a strategist-like capacity on process and mentorship, and unofficially "product manage" the growing automation backlog. 

Because I get asked this a lot, I'll touch on this here for anyone interested in following up - here are the tech stacks we're currently using to automate our UI/E2E testing:

• XCUITest for iOS
• Espresso for Android
• An in-house wrapper around FlaUi Automation Library for Windows (WPF)
• Cypress.io for Web
• ...with more to come as the team grows.

Wow it's been a crazy 3 years! And the adventure still feels like it is just beginning. Feel free to reach out to me with any questions, thoughts or challenges you have for me in regards to any of this. I'm always happy to share my thought process, experiences and to learn more from others' experiences as well.