Being Dunelm’s First Platform Engineer in Test
I joined Dunelm in March 2020 with nine years of experience testing websites, mobile apps, and other consumer-facing applications. So, when I took on this new role in the Platform team in October 2021 it was a major shift for me as I had to grasp a bunch of new skills and adopt a new mindset that was quite different to what I was used to. Interestingly, this was not only a new experience for me but also for the Platform team here at Dunelm as I had just become the first Platform Engineer in Test (or PET, though I still try to avoid using this awkward acronym when telling people what I do). This job title differs from the more recognisable one of Software Development Engineer in Test (SDET) because with this role we aimed to open a whole new area of testing, so it warranted a whole new title.
Platform at Dunelm
At Dunelm, we’re proud of our serverless architecture with most of our services being hosted on AWS. We have 16 feature teams (on the digital side) that work on various areas of the business and Platform is in many ways a support team to others as we endeavour to help them work better and faster. This is made possible by things such as maintaining the infrastructure that all the teams use and investigating and implementing better tooling. We take pride in using the best tools for the job and this is not limited to the use of Terraform, which is an open-source IaC tool for provisioning infrastructure. We use Fastly as our CDN which allows us to deliver content to the website faster through their edge cloud platform. We also recently migrated from Bitbucket to GitLab for our source control and CI/CD capabilities which was an enormous project due to the large number of microservices and projects we have here at Dunelm.
First Few Weeks in Platform
With my lack of Platform related experience, the learning curve to pick up the new technologies and terminology used by the team and the scope of our work was quite high. The priority for the first few months was to help establish what testing in the Platform space should look like and some of the challenges I faced included:
Ways of Working
As this is not a feature team that produces fancy new ideas and then delivers them to our end users, many of the processes that I was used to weren’t always appropriate. Of course, I had to learn these new ways of working but we also found it beneficial to formalise some new activities that would better suit how the Platform team does things. I will outline these later.
GitLab Adoption
The migration from Bitbucket to GitLab not only consisted of transferring hundreds of repositories but also spreading this knowledge and training engineers to make use of this great new service to the fullest. One way this has been achieved was through an internal shared pipeline library that a few members of the Platform team created. As a result, learning and contributing to this project was a major requirement for the early days within the team.
Technologies Used
Perhaps the biggest challenge after moving to the Platform team was the number of tools that are being used which I had not yet worked with. It was a bit like reading the back of a packet of sweets and seeing a bunch of unpronounceable ingredients - It wasn’t that I simply didn’t know a lot of the terminology but I hadn’t even heard of some of them before. Fortunately, many of us within the Quality Chapter had been encouraged by the Head of Quality, Stuart Day to get our AWS Certified Cloud Practitioner certification. This gave me a good foundation for much of what the Platform team does on a day-to-day basis.
Testing Setup in Platform
Before Dan joined the Platform team as the Principal QA Engineer in early 2021, there weren’t any formal testing processes in place. However, when he moved over, he was quickly assigned to work on other high-value projects such as the GitLab migration and certain infrastructure changes. As a result, he couldn’t tackle the testing issues that he had originally joined for, and this issue magnified the need for an additional QA in the team.
Within the Platform team, Dan and I work with ten developers so you could say we’re a little outnumbered especially since the engineers work on so many different areas of the infrastructure. To make it manageable, we decided to identify the most important areas and tackle them first, so we don’t get too overwhelmed. We started by chatting with the Tech Lead and Principal Engineer and together, we produced a list of three areas that demanded our attention most of all. These were: Fastly, Backup of AWS resources, and monitoring & alerting.
To help us with this, we started having Three Amigos sessions before any development took place for these tickets. The purpose of these meetings is to identify the main test scenarios for the task and to make sure that we’re all aware of how it can be tested. If there is a need for some automated tests, this is where we would agree on what is required. Another great benefit of these discussions is that they expose the developers to the quality mindset which doesn’t traditionally happen in this space. We also found it worthwhile to pair with the developers whilst they worked on the ticket at hand. However, even more than this, we really benefited from picking up tickets and bug fixes ourselves because both Dan and I find that we learn best through doing. This led to us finding several issues some of which had been present for quite some time such as Terraform syntax inconsistencies and a few services not working as they should be.
Naturally, we added some automated tests for these issues but more importantly, we used it to fuel our reasoning for adding some unit tests as this is commonly disregarded when working with Infrastructure as Code tools. After development, we try to have another quick catch up where the engineer walks us through what they’ve done and any caveats or concerns they may have. Then we review the merge request and carry out our testing and if all is well, we would approve the MR and consider this task ready for deployment. This process although simple is major progress compared to where we were before as we previously had minimal testing which was mostly on an ad-hoc basis.
Benefits of Having QAs
Being the first Platform Engineer in Test at Dunelm makes me retrospectively assess whether the team benefits from having a QA presence. I feel that the answer is a categorical yes. This is not only due to the obvious fact that we now have more testing processes with improved coverage for some of the most important services being used in the company. Possibly more than this, is that we have a team of engineers that have benefited from an enhanced awareness of the importance of testing with the option of reaching out to us QAs to discuss their needs. Even though this is not yet a trend in the software engineering field, many companies would benefit from having a testing presence in their Platform team.
Key Learnings
I have learnt an incredible amount in the short space of time I’ve been in the Platform team. I want to share a few points that I hope can help others that are interested in joining this space.
- Get your hands dirty: If you take just one thing away from this post, let it be that you absolutely should pair with engineers or better yet, take on dev tasks yourself to help you grasp things quicker
- Be a sponge: The initial months are crucial so try to learn everything from everyone even if it doesn’t make sense yet
- Don’t be hasty: Don’t try to achieve everything all at once. It is far easier to tackle a small number of areas first rather than trying to do everything at the same time
The Future
As mentioned earlier, our Platform team has a ratio of ten developers to two QAs and this prevents us from covering all the areas of our remit sufficiently. The wider umbrella of Platform Operations is also huge, so we expect the QA presence within this space to evolve not only in number but also in terms of what the role entails and that is undoubtedly very exciting.
