A day in the life of a QA Engineer

Gareth Thomas
Purplebricks Digital
5 min readMay 7, 2021

Gareth Thomas | Senior QA Engineer at Purplebricks

Sometimes you have to approach the product like a beginner…

I’ve been at Purplebricks since 2015, and the transformation in people, ways of working, the products we deliver and the platforms we deliver them on has been amazing to be a part of—but one thing has always remained consistent; a focus on quality. While we have both manual and automated QA engineers spread across the whole of Digital, I focus almost exclusively on our mobile app.

07:30 to 09:30: The early bird gets the bug

I’m a relatively early starter (working from home makes this much more palatable) and I like using this time before everybody else logs on to get some quality testing time in.

While it’s rewarding to be considered a resource for your team to lean on whenever they have questions about certain flows or functionality, so too is having a pretty big chunk of uninterrupted time to eat breakfast and plow through any completed development work, or like today, write about how valuable this uninterrupted time is!

We’re very collaborative when it comes to ‘test effort’ at Purplebricks, so this tends to comprise of final testing which, dependent on the change, might mean testing some edge cases, approaching it like a user on a physical device, or checking it for specific issues on a range of different devices which is enabled by our partnership with Browserstack. Hitting this work early means I can usually give an accurate update at our stand-ups.

10:00 to 12:00: Stand-ups, refinement, box sessions and customer reviews

Our squad has been together for quite a long time now, and there’s a high level of trust and communication, so our stand-ups are as quick and on-point as they should be. The App Experience team is currently working on some large, exciting changes and as such, our product backlog requires some refinement.

As a QA, I find my main value here is as a (self-described) product expert. Knowing intimately how each flow works, common pitfalls and where and how our customers will come in and out of the app and website during their journey means my team can lean on me as we’re deciding what each piece of work actually looks like, the areas of code that may need change or consider, and crucially, what acceptance criteria we’re going to be designing, developing and testing against.

Over the past year, the QA team has engendered a culture of quality across the whole digital team, reducing the responsibility that falls solely on one or two QA engineers at the end of the product lifecycle. An important step in this ‘shift left’ has been our design and dev box sessions.

This is where early iterations of new work are demonstrated to the team for us to evaluate. Mentally running through the acceptance criteria I defined means that the manual testing load is reduced or removed altogether, and my teammates and I can point out where we need to quickly make changes or go back to the drawing board altogether. Any tester worth their salt knows the earlier a defect is found, the cheaper and easier it is to fix!

As one of our most visible and therefore key metrics on the mobile app, customer reviews are of paramount importance to us, and we review them on a weekly basis. We’ll take on board the comments, suggestions and ad-hoc bug reports that make up these reviews and map them against our existing backlog, use them to prioritise future changes, or try to replicate the problems reported ourselves.

Just a few of the tasks a QA Engineer might get up to at Purplebricks

13:00 to 14:00: Collaboration and investigation

In the afternoon, with the majority of our meetings over, I get a lot of requests to collaborate with others across the Digital team. This might mean working with a Product Manager on our backlog, teaming with developers to try and pin down the root cause of a bug, setting up some test data for a specific scenario or teaming up with design to walk them through a flow and determine if their new ideas are feasible or whether they’re missing something crucial.

Naturally, we also work closely with our automation engineers. Collaboration with them usually means reviewing the development work in the last sprint, going over our acceptance criteria and test scenarios, and determining which of them are a high priority for automation.

I truly believe that good quality assurance is just as proactive as it is reactive

Investigation is a key and oft forgotten part of quality assurance. As meetings and collaboration tail off later in the day, I’ll use this time to look into issues reported by our customers in a little more depth, changes to devices and their operating systems, new changes from our colleagues working on the website, or most recently mapping all the analytic events we have and those that we’re missing.

I really enjoy these investigative tasks. You might question why this falls on the shoulders of a QA engineer, but I truly believe that good quality assurance is just as proactive as it is reactive. We can gain a deeper understanding of problems and the usage of our product through these events, and without them, we have an incomplete picture. Isn’t ensuring that we have the means to know everything we can about our product quality assurance?

14:00 to 17:00: Personal development

As I’m writing this on a Friday, it’s only natural to include this. In the Purplebricks Digital department, we’re fortunate enough to be given half a day every week to spend on our own development, and we have a number of platforms we can use for learning.

We’re given the freedom to study any subject we like. Right now, I’m studying UX and UI design, so I can better evaluate the product before a single line of code is written. I’m also looking to learn a little about API testing with the longer term aim of creating some tests to sit in the build pipeline.

Due to the autonomy of this training time, I might tailor it for shorter term goals, investigating a new tool or testing out new features of existing tools.

As you might expect, there really is no typical day at Purplebricks. Due to the need to often shift focus, a QA engineer here might have to be part tester, part quality coach, part designer, part product owner and part developer hour to hour, and that suits me perfectly.

--

--

Gareth Thomas
Purplebricks Digital

Product designer at xDesign. Former QA. Plyometric fanatic.