What's in a title?

April 2024

The job titles we have matter sometimes, but at other times not so much. A job title can sometimes limit people's understanding of what we can do, but at the same time they can sometimes convey succinctly exactly what we do do.

Over the years I've had many job titles and roles, including

Tester Software Test Analyst Quality Assurance Software Quality Engineer Automation Quality Engineer Quality Coach Quality Analyst

Support Engineer Software Developer Logistics Manager Father House dad Chauffeur Programmer

Production Scheduler Operator/Scanner Volunteer Organiser Chair Treasurer Tram Driver

Some of these will have meaning for you, others may mean little without knowing more of the context.

---

Recently I've been thinking of what I am, and I've landed on

I am a Software Quality Engineer

Although, I do feel a little conflicted because quality is really an attribute of something, not some we can engineer by itself. However, the title seems to have gained traction over the recent years as meaning a broader engineering role focussed on software quality, which I can certainly sign up to. We build and engineer tools, systems, and processes to help us efficiently analyse and monitor the quality of software solutions. Testing is a wide and varied endeavour, but there is real value in being able to quickly get basic quality information about a code change through automation. The objective being to automate the boring and free up the tester to explore more and deeper. Automation of course, covers so much more than simply automating the product itself, but also in preparing the product to be ready for testing, the local development environment, the version control and branching strategy, the CI/CD pipelines, the creation of test environments and infrastructure, the preparation of test data in an environment, the capture and aggregation of (test) environment logging and monitoring data, and much more. All of these tasks may lend themselves to degrees of automation, and can each take a serious chunk of (boring) time to do without the automation. Creating the whole interconnected ecosystem necessary to efficiently determine the quality of a software solution I believe is a genuine engineering activity.

My old (pre 2024) intro ...

In the blurb at the top of my CV I used to call myself a Full Stack Agile Quality Analyst (original text below). However, I feel it no longer fully resonates with me, some of the words like "Full Stack" and "Agile" have had their day. We now generally expect people to adjust to the context they've been placed in, to simply get on and do the job as best they can with the resources available. To be able to recognise the things that need doing the most, to communicate concerns and ideas, and to have a shared commitment to achieve the most for our users, customers, team mates, and organisation. Full Stack seems to me to mean you're happy to google for (new) solutions to a problem on your plate, rather than simply handing it over to another person in the organisation. In addition, Agile seems to have become a de-facto industry norm. Of course Agile is hard to do properly, but saying you're into Agile development seems superfluous these days.

Intro - I'm a Full Stack Agile Quality Analyst I love testing and will use all resources & tools at my disposal to do it. Every delivery team has different constraints, skills, processes, bottlenecks, and opportunities for how they deliver product & process changes. I'll try to leverage the skills and resources already in the team, and add my own skills and experiences, maybe sprinkle on some ideas from the test, agile, and dev communities, as well as, some plain experimentation, to best test and deliver the changes. Each context is different and I love adjusting the development, test, and delivery processes to match them to the context at hand. I like exploratory testing, and I also have fun coding automated checks. I do gravitate towards Context Driven Testing (CDT), and (largely) agree with the thoughts and expressions from the leaders of the CDT community, such as James Bach and Michael Bolton. I really like Agile, which for me is "autonomy with responsibility through trust". I think the essence of software development is still about people: It is Driven by people, Made by people, and Made for people. We all have emotions, passions, motivators, and more! We're all different, and we all have something unique to give.

I love to work with people that have a passion for what they do, and have fun doing it! Testing is my professional passion, and I love working with people who respect and challenge me to be my best.