Looking ahead to TestBash 2025, and back at recent episodes of The Testing Planet, I hope youâre all as excited as I am, to dive deep into topics like Quality Engineering and Quality Coaching.
But whats in a name? And are you maybe doing some of this already?
Iâd love to know, what you think are the key activities, skills and tools you use in your job, and what your job title actually is?
Also, Iâd love to know, what do you consider to be âpart of the day jobâ, and what do you consider to be going above and beyond, or outside of your role description?
Over the last 4 years, Iâve found it liberating to be called a Quality Engineer, because I feel it allowed me to get involved in the full SDLC in ways that were considered âExtraâ and not core when I was a QA Engineer or Test Engineer in previous roles.
It might be, I changed, or even that the teams and company structure Iâve been in were different, and this wasnât magic from the job title, but maybe more about the organisation and leadership around me, and my perception.
So what is your experience? Is there anything youâd love to do, you feel held back from because of your current title? or work you do, that isnât recognised as part of your day job, so you donât get the credit you deserve?
Whatâs in a name. A very good question, I donât like to look at job titles, theyâve thrown everything at me so far. From Quality coach, agile tester, automation engineer, performance tester, technical qa engineer, pentester, devops engineer, chapter lead, guild lead, even PITA (pain in the @$$) works
I mean⊠on all of the projects I kind of do the same thing no matter what my role is. I go to companies, join their teams, I find bottlenecks/challenges, improve the quality of the teams based on the project/ coach teams (devs, testers,po/SM/analysts/âŠ), bring up some painful wounds and try to cure them. I make myself replaceable and when I am, itâs time for me to leave. #RealConsultancy
Personally Iâm never held back with any title. I just have a lot of knowledge about a lot ⊠not always a specialist but I know what to talk about I suppose and I know how to press on a wound which is a big asset as a consultant, Iâve always started in a specific role at a company and I always grow faster to other places.
I act on things, when people say âwe are going to do this in the CSP or cookiesâ and Iâll just be like âhey invite meâ and at some point, they"ll do something wrong and Iâll point it out, giving them the insight that I know stuff about that topic and theyâll automatically come back to me. Theyâll say âHey, maybe drag Kristof into this, he seems to know stuff about itâ. This is how usually the ball starts rolling
Example of one of my clients: I had an interview to become a agile tester in 1 of their teams, I got hired. On my first workday, somebody else got my job role and I got told Iâm the Quality Coach/Test Co. (I didnât mind) I got into a few meetings, scaled a few security risks that I saw, I became security champion of 7 teams. The week after I became the coach of some testers.
Still on my contract it says âagile testerâ
1 month in my new client, I got approached by one of the other teams (not under me) because they someone knew who I was and what I did (meetups etc), they explained they needed knowledge sharing amongst all testers of the company. ~50
So I started a Testing Guild in the company and became guild lead.
2 months in, Iâm coaching developers how to create REST APIs, doing architectural meetings as QA.
Still on my contract it says âagile testerâ
I donât look at my contract title, a title is a cover of formality. What really matters is how one behaves on the work floor and how they are able to move projects for better quality.
Thatâs my experience Thatâs how I try to improve the quality of my clients, by not just sitting within my team but expanding to challenges I see and where I can help.
So no, I do not let a title stop me
I wouldnât be a good consultant if I did
From where I live they call someone in QA an âEngineerâ when they can do automation and coding and âTesterâ when they only do Manual.
These titles seems only being thrown away on job postings. Thereâs also one Iâve seen called Software Development Engineer in Test (SDET) which seems kinda cool but is just like any other Software QA Engineer.
Also I remember from my studies that QA is process-oriented and QC is product-oriented. Not sure if itâs applicable everywhere else because I think companies and experiences define what people know.
I see the issue of role nomenclature from the following perspective.
On the one hand, if a role is focused uniquely on testing the product (the process output), here the goal is to adhere to raising risks about the product itself. It doesnât matter if the tests are done manually or with the help of other tools (like automation). The role has not any influence on the way the product is developed.
This type of approach happens a lot in organizations that donât have a collaborative culture or that are transitioning in their way of working.
On the other hand, are roles with a focus oriented to how the process of product creation is carried out. These roles, and they are the âfortunate and also the most seniorâ, can help inspect all the processes and moments of software development. They collaborate in a very integrated way from before a line of code is generated. Of course they inspect the product also but here they are not limited only to check the product.
And again, it doesnât matter what tool this person uses to help raise potential risks.
In this case automation is in harmony with the product development because all roles are speaking about how the product is going to be tested and this is taken into account during the coding process.
When I first started work, I was all about making sure the work I did matched the job description and role title. But over time and where I am today, I really couldnât care what my title is or job description.
To me a role is dictated by 2 elements: objectives and tasks. The trouble with job descriptions and role titles is there is a fixation from employers that they have to focus on tasks and skills. The one thing that overrides all that are the objectivesâŠwhy are you here? Thatâs the part you have to own. You own those objectives, you evaluate them and adapt them as you move through them, until you feel in your role there is nothing more for you to add to the organisation.
I feel very lucky to be in that position. The tasks I do are whatever they need to be to achieve my objectives around improving quality and efficiency. For example, engineering productivity was suffering from interruptions from Customer Success querying customer issues/complaints. I put measures in place to evaluate those interruptions and could see the majority of them, were not faults. The issues were purely investigations being passed directly to engineering into the sprints which became standard practice. So I worked with them to produce a new âsupport ticketâ process where they tried to own the investigations until they exhausted their knowledge before raising an engineering ticket. The support ticket was dealt with by engineering, but we would also look at why the customer success team felt they couldnât perform that 1st line service and raise appropriate tickets to improve the product observeability.
My job title is âTest Leadâ. Nowhere in my job description is any relevance to the above and I donât care. Iâm owning the quality objectives we have set.
Regarding the roles,all of these aim to ensure quality, process improvement and each role contributes in its own way to delivering high-quality software.
My job title is âQuality Engineerâ, part of my day job involves testing a web app, focusing on functionality, regresssion, exploratory, negative and sanity testing. I truly love doing this as tester, even though it often goes unrecognized. I take pride in ensuring that everything runs smoothly for the end user
Thatâs how I try to improve the quality of my clients, by not just sitting within my team but expanding to challenges I see and where I can help.
