It’s going back a decade ago when we first set up our test guild to look at our practices, value, training, consistency, tools etc.
The single biggest problem was that across the company there were about 50 different views on what testing was and the value our testers brought to the table.
We created a survey for across the company, often with fairly open questions. This gave us a baseline view of what others and even the different views from testers themselves to see what challenges lay ahead. There was some fantastic feedback but also a lot of very dated views on some elements of testing. It also included what they needed from testers that was at times missing. *I also noticed some things developers thought were a bit boring and wanted to palm off to someone else - I’ll mention that a bit later but one thing we pushed was that test cases are for developers and not testers in our model and that ended up being significantly positive overall.
From there we first aligned within the testing group our goals and values that we intended to bring to the table, this revamped role definitions, skills targets. Average working week guesstimates can help with this.
After we were aligned we picked around 10 influential people in all roles to get buy in, some changes were made following this and then we ran out a new knowledge share session in small groups to everyone.
That was the biggest challenge and also the most important step our group did, do not do it entirely independently as a QE group, they will ignore you and stick with their own beliefs about what QE is.
From there we went went for more common changes and pain points (pain points can also be gathered from the survey and discussions).
Just an extra thought as you are talking QE which in my view carries significantly different bias’s from testing where testing focuses on the discovery, investigation and experimentation of risk which ended up being our focus, QE can push for more focus on the build side of things, CI, building test frameworks, automation, test operations. Going back to my earlier point, developers will at times hand over tasks they just don’t enjoy so much even if they are the most efficient and most appropriate person to do it. QE might carry a higher risk of doing a developers job than what we ran into.
