Bureaucrat, staff, administrator
477
edits
Changes
m
no edit summary
'''April 2024'''
The job titles we have matter sometimes, but at other times not so much. A job title can sometimes limit the 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 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 I? And , 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 blurb ... ==In the blurb at the top of my CV I used to call myself a '''Full Stack Agile Quality Analyst''' (I've included the original text below). However, I feel it no longer fully resonates with me, some of the words like "Full Stack" and "Agile" had 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 just 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.
{| class="wikitable" style="margin-left: 50px; margin-right: 50px; text-align:left"