It’s been more than 5 months since I started at Quality Minds and shifted from working as a software developer to a quality engineering consultant. For most of my 20-year career, I would not have considered working in consultancy – being with my family is way too important for me to risk having to travel a lot. But a global pandemic changed rules that seemed to be set in stone, and since I knew some of the special, kind and lovely folks at Quality Minds, I felt ready to start this adventure.
After an onboarding period, I thought that I would soon be starting to help clients with test automation, getting to know frameworks like Selenium, Cypress, or Playwright. I even started working on an ISTQB Foundation Testing certification and learned a couple of things from a different perspective.
I got hired by a client pretty quickly – but I wrote hardly any test code so far. I wrote one gherkin step and I wrote some JUnit assertions, but only as part of TDD-based micro-tests (which is what I nearly always do when writing any code).
Doing the right thing
When I started with my client, a colleague and I got introduced to a classic legacy project where a lot of information from the beginning had been lost due to changes in the development team members. The plan was, that we would help with writing cucumber glue-code, creating test-strategies and implement new features that would allow testers to automate their scenarios.
It took just two weeks for me to realize that this would not at all help the client achieve their goals. What they needed was an experienced developer who would fight the immense technical debt that was buried in the codebase and adapt the existing architecture to the requirements that had changed massively since the project’s start. Someone who could reveal the problems and educate the developers on how to do it differently.
I proposed that idea pretty quickly and started to do what I was convinced would help the client. It felt uncomfortable to act clearly outside the role I was officially hired for, but I was encouraged greatly by one of our CEOs, Michael, whose mantra is: “First, do the right thing”.
Eventually, the client accepted the change of goals and even installed me as a dev-lead for their little team.
I can’t tell yet if we will achieve all of the client’s goals, but we already made some progress and are in much better shape than we were 5 months ago.
Quality Engineering is more than Test Automation
One reason why I write this blog post is that I want to point out the things that I did to improve quality for my client (whether it is the quality of the software, feedback, collaboration, or team spirit is sometimes hard to distinguish) without doing classic test automation:
- Creating a clear class-model that reflects the most important entities of the domain; collect that in one central place
- Extracting information about relationships of the different entities into an easily human-readable form (I love you, Excel), making it easy to understand and change
- Reading code. Lots and lots of reading code, understanding what it does, and investigating the reasons why some decisions had been made. More reading code. Adding comments.
- Speaking with people. Asking a lot of questions and understanding the domain well enough to map it to the code
- Identifying duplicate logic and eliminating it via different refactoring techniques (interfaces for the win!)
- Identifying concepts and making them more visible via different refactoring techniques or comments
- Pairing with developers. Understanding their way of working and eventually offering different approaches
- Doing little tech talks nearly every week about concepts that might help them in situations I watched them struggle with
- Clarifying terms that can have different meanings
The list is not exhausting, but nothing of the things I did in the last couple of months has had anything to do with the test automation tasks I would have expected. And still: all of these things had an impact on quality.
I’m very much looking forward to how this journey will continue and I’m very happy to have the support I need to “do the right thing” – no matter if it’s officially written down in my contract or not.