I am doing some research on this topic and would like to hear from experts and practitioners who have a Quality Engineering (QE) group at their workplace.
I have three main questions.
What roles exist within your QE team (e.g., SDETs, Test Architects, Quality Coaches, Automation Engineers, etc.)?
How is your QE function evolving in your org. What’s working well, and what challenges are you facing?
Where do you see your QEteam heading in the next few years as testing and quality practices mature?
Quality Engineering is just a different view for Quality Control, introducing the idea of integrating testing into CI/CD pipelines and making quality an integral part of Software engineering. That is the view I can see from my organisation perspective.
The role of automation engineer is being replaced by SDETs. They can either move to software architecture or to Test Architect.
Quality Engineering is blurring the differentiation between developer and tester. It has driven quality to be a responsibility of the team rather than a responsibility linked to testers only.
Quality Engineering team will consist of quality engineers with the team being lead by a QE lead or Engineering team lead and eventually become merged into the Engineering team. There are drawbacks to this.
I’m still getting my head around the QE concept, in some cases it seems just what our testers have been doing but in other cases it seems a lot for a single person.
From a business perspective we are a team of quality consultants, internally we are testers who can do quality consultancy.
Our small team 4 testers to 80 developers did broaden our scope about 5 years ago, all specialised in exploratory testing but each with secondary and tertiary specialisations. Automation including architecture, security, quality planning/management, coaching, training, customer support and also dev ops activities environments, pipeline etc .
I suspect that as team comes close to the QE view but we all remain primarily testers and none of us as individuals can cover all of those activities, that’s partial skill matching and a decent amount of preference, I don’t enjoy devops pipeline things for example.
It’s worked quite well, note we are often solo on projects and across multiple projects as individuals yet we utilise a call a friend option rather than try and get all the skills in a single tester.
What roles exist within your QE team (e.g., SDETs, Test Architects, Quality Coaches, Automation Engineers, etc.)?
Our official titles are all some variation of “QA Engineer”, with words added to signify seniority. I’m sure what we do in our respective teams has some variation, but in general, I’d say the official title doesn’t have too much meaning, in terms of dictating what we do(n’t) get involved in.
How is your QE function evolving in your org. What’s working well, and what challenges are you facing?
A new thing that was introduced the day I started one year ago, was a Staff QA Engineer who’s not part of any one team, but rather works with and across multiple teams, collaborating with the quality specialists in those teams. Whilst I think this has benefited us a lot, in terms of having someone who knows enough about all domains to connect the dots, there’s always the danger of that meaning we don’t learn so much about the other domains ourselves. That is something we’re actively working to improve.
Where do you see your QEteam heading in the next few years as testing and quality practices mature?
I’m honestly not sure. Since we don’t have a separate QE team, so much as QEs embedded in development teams, there’s not the same standardisation of approaches that I’ve seen in other organisations. Teams are generally able to make their own development decisions, meaning that the contexts can be quite different for quality and testing, as can the approaches or maturity of the teams.
Well I rebranded the team about 6 years ago to Quality Assurance, as we were called the Test Team and hence we were only invited to the conversation if it was about testing. When is it never about Quality? The next rebrand more recently was to deal with this perception that Automated testers were “better” than Manual testers, so I called the manual testers “UX Test Engineers” and the Automation Engineers “Tech Test Engineers”. UX being the experts on “WHAT” to test and the Tech being the experts on “HOW” to test it. I have no doubt It’ll evolve again as I’m discussing the difference with Quality Engineering with all my peers.
So as the QA Lead I’m coaching the team in Quality Engineering techniques (while I’m learning them), influencing others by adopting the role of a Quality Engineer/Coach where I can and proving the concepts. Thats continuous education but its beginning to stick which is great. But its tough as there will always be some that don’t get it or see it as an important distinction, hence it can be 3 steps forward and 2 back. Also some of the testers are happy being testers and feel quite rightly that a Quality Coach is not their strength. So its a case of never giving up and being patient with the message.
I think we’ll be driving more conversations about quality from the outset, but not as a transaction at an earlier stage, but starting those questions there and seeing them through as a collective and being catalysts of ensuring quality faster, rather than delaying the process. But its pretty clear at this early stage, that there is comfort zone to being “a tester” for some and it’ll take time and patience for them to adapt their thinking.