Are we now continuously responsible for the quality of a product team, delivery team, compliance team, support teams , engineering team, operational team, legal team, leadership etc as Quality engineers. How do you get skilled at quality engineering? It loses its meaning if it means everything?
A lot of the CQ phrases sound like good engineering, observability, testing, and monitoring practices â not a distinct practice called âCQâ.
Are we creating roles with impossible scopes?
I think this is an excellent reflection. What do you think? Are we creating roles with impossible scopes? If so, how might we address this issue? How might folks and companies lead with quality to clearly define role scope and responsibilities?
If you look at any job description these days, I think that will answer your question .
QAs nowadays are expected to get involved in every part of the software development lifecycle. Whether thatâs good or bad, Iâm not really sure either way but it does feel like the scope gets bigger every year.
I think we need leaders that really understand what quality is for themselves, their teams and their companies to correctly define scope and responsibilities.
Thatâs kind of a vague statement as I donât really know how you would go about this but the first thing needed is buy-in from the company.
You need leaders to be given enough space to identify what is needed for quality and enough space to build it, in my opinion.
I think some leaders outside of QA are guilty of âsolutionizingâ what they perceive to be the quality problem, mixing it with what they think testers do and then producing a job spec that is a catch all. Because imagine if the quality problem wasnât what they thought and its not in your job description?
I remember when I was recruited 7 years ago in my current lead role my brief was âAutomate 100% of tests in selenium, line manage the team and recruit more testersâ. Theyâd put the job description together as a catch all because they didnât know if they needed more a manager or more a tech tester, just to see if they could get lucky. Fortunately my role has evolved so much, that I no longer recognise that job description or care what it says. My role is my role and it evolves to what ever is needed as a quality advocate and leader. It keeps me interested as my role evolves. Its quite unhealthy when you think about it to be nailed to a job description.
So the first role to recruit is the person that will dive into the quality problem - without the leaders trying to steer the conversation. Theyâll come up with a plan and somewhere in that process, propose the roles needed to architect a testing function. I think thats the only way to avoid broad catch all job specs.
For a broad sense, I could resonate with what @rforjoe mentioned in the linked post: âcontinuous testingâ is a concrete, technical practice, whereas âcontinuous qualityâ is broad, fuzzy and ambiguous.
I know it(CQ) has good intentions based on the interactions I had with multiple teams, but it risks diluting the QE role into meaninglessness.
When everything is your responsibility, nothing is your speciality, and what we really need are testing experts who make quality visible and achievable for everyone else. We need QEs to be exceptional at making quality measurable, achievable, and sustainable across the organisation.
A small example of their scope could be to âfocus on influence instead of (traditionally) controlâ:
Providing frameworks and tools
Helping teams to unveil quality risks
Coaching team on testing practices
Building visible systems to measure what matters for quality
Advocate for Quality (not ownership) across teams
No individual can meaningfully influence âeverything that affects qualityâ. What I think is ideal would be to set clear boundaries, distribute ownership, and invest in building systems that make quality everyoneâs responsibility.
Where did this new job title come from? If testers just started calling themselves Quality Engineers, itâs meaningless and looks like a power grab to get involved in things that arenât their business. If so, stop doing it.
If employers invented the title, which I doubt, they should define the scope and responsibilities, which of course they should do regardless of your job title. If you think the scope of your role and responsibilities should change, discuss it with your employer - itâs not for you to do unilaterally.
I believe what used to be called âSDETâ years ago, in few fortune 500 companies. Today has become ubiquitous as âSr. Quality Engineer/Quality Engineer/Automation Engineerâ etc and used by many companies. The obvious connotation is that once âEngineerâ is in the job title, then a lot more technical expertise is expected, with innovation/adaptation to new tech stacks and hence the lengthy list of scope and responsibilities. The market has also witnessed massive influx of âTest Automationâ solutions over the years. Ultimately it comes down to saving costs on that extra Developer or QA or Release Engineer etc.
I think that testers getting involved with âqualityâ as a title or named responsibility is a big mistake, at the very least in terms of PR and accuracy. I think that testers are placed further than most when it comes to influencing product quality. They do not make changes to product code, nor final design decisions. Nor do I think they should, generally speaking. It may be that the quality improvements a tester may suggest in terms of fixes and additions do not make good business sense. That is why we separate those responsibilities. It is also putting testers at odds with their own purpose - to critique the product and to design and build the product means making decisions that favour one thing or the other.
Testers seem to want to create roles with impossible scopes, not so much in terms of the breadth of their work (testers do what they can with the resources they have, like anyone else), but in terms of responsibilities they simply do not have the agency to affect directly.
If we want the world to know that testers donât make quality then it seems prudent not to put it in our job titles.
The term âEngineerâ also implies some level of formal training, usually to degree level - below that, most disciplines would regard you as a technician. This in turn implies that there is some body of knowledge that is agreed on by engineers in that field, albeit that this changes over time. None of that exists in software testing and it certainly doesnât in âquality engineeringâ, whatever that even is.
I think companies are seeking people who even though donât have master in any trade but if they have jack in all trade it will work for them.
One of the reason is that companies are thinking their apps donât need so much in depth testing, even if the client report few bugs that will be fine.
So with this mindset for e.g. instead of hiring any particular performance test engineer they prefer their someone who has automation skill and general knowledge of jmeter.
Thatâs just one example, however when we see around we will almost every company following same mindset to avoid cost and hire someone who doesnât have specialization in all but can atleast do all the task even it require help of ai tools.
I donât think that is a vague statement. It is a very good point in terms of leaders understanding what quality means for their team and company! I have walked into a few situations where theyâve had a good go at trying to define it, but need a little assistance on expanding it further.
I donât believe we are responsible for quality, but we can be consulted.
A few years back I learn something called a RACI matrix - responsible, accountable, consulted and informed. Those words I do find useful as thereâs different meaning to them. One example I could give is that I am not responsible for monitoring, but I can notice a gap that itâs missing. Then itâs up to the team responsible for that to sort it out (in this example they did).
I have observed the confusing job descriptions. Itâs up to the managers of whatever domain, in my view, to create ones that make sense and articulate what a person will be doing every day. I
.