Does the topic title include a “question mark”?
What are you asking of the community?
How can they help you?
What context can you share to increase the likelihood of someone replying to your question?
In many organisations today the senior leadership seems to be from a developer background and hence biased towards developer roles. This sort of mindset is damaging to the testing roles, since this often leads to the testing functional being included in software development function in such a way that this it is treated as a tick box exercise or an overhead.
The best value of testing can be achieved through it being independent of software development so that it is able to improve the software by finding problems with processes, performance and question the release of the product. That being said most skills in software development such as coding, understanding of the architectural aspects, the infrastructure aspects and code implementation can be included in it. This is where QA engineering comes into play.
But these days there is a shift towards the thinking that testing should be absorbed into the development process and hence more senior testers are leaving the profession to move on to delivery management, software development manager or change management roles for growth in their career.
What are your thoughts? Do you agree with me? What do you think should be the way forward?
I don’t see it as an “either/or” proposition, although I wouldn’t be at all surprised if there is a move that way from the upper management types who can often have difficulty understanding the value testers can bring (mostly, I think, because it’s not directly observable value: it’s more implicit in the number of issues that didn’t reach the customer and the regular reports of the status of the software - more like insurance than a direct expense offset by product sales).
I don’t see a problem with senior testers moving to delivery management or software development management. Their experience as testers will give them different perspectives in their new roles, and if they enjoy the change I can only applaud them.
On the other hand, I’m sure there are plenty of senior testers who are happy to stay in the roles they have for as long as they can, and they’ll continue to provide value while they remain there.
Yes, there are times when testers have to ask awkward questions that cause developers a lot of rework (questions like "Is this feature supposed to work with configuration option Y? Or “How are we securing the user’s credit card information?”) These times help to convince managers that it’s a good idea to let their testers review the documents earlier, because it means less work (and expense) in the long run.
The people I feel for are the testers who have been trapped in the view of testing as a check-the-box exercise, especially when it comes with “Thou shalt not deviate from the Test Script lest Management smite thee from On High.”
Test scripts and checklists are helpful to remember everything that needs to be covered in a large project. But going off-script is usually where the most interesting and gnarly bugs lie.
@mo_sid Your insights into the changing landscape of testing within organizations are truly thought-provoking. They highlight the complex dynamics at play and the critical questions surrounding the future of testing roles.
It’s undeniably challenging when senior leadership comes from a developer background, as it can sometimes create biases that affect testing roles. Striking the right balance between maintaining testing’s independence and integrating it into the development process is crucial for ensuring the effectiveness and value of testing activities.
I wholeheartedly agree that testing should retain its independence to effectively uncover and address issues across processes, performance, and product releases. At the same time, there’s immense value in embedding testing skills and expertise into the development process to uphold quality throughout the software lifecycle.
The trend towards integrating testing into development processes is understandable, driven by the need for speedier delivery and enhanced collaboration between teams. Yet, it’s vital to ensure that testing retains its essential role in quality assurance and risk management.
Ultimately, the path forward will be unique to each organization, shaped by its context, goals, and culture. Finding the delicate balance between independence and integration while fostering appreciation and empowerment for testing roles is key to achieving optimal outcomes in software development and delivery.
I’m genuinely eager to hear from others and learn about their perspectives on this topic. Let’s continue this dialogue and delve deeper into the diverse viewpoints within our community to navigate the challenges and opportunities that lie ahead.
I agree with you that it’s not necessarily an “either/or” situation when it comes to the integration of testing into the development process. While some organizations may lean towards absorption, others may prioritize maintaining testing independence. Ultimately, the value of testers’ insights and their ability to ask critical questions cannot be understated, regardless of their specific role within the organization.
Your mention of testers asking awkward questions that lead to improvements resonates deeply. These moments indeed showcase the indispensable role testers play in ensuring software quality and mitigating risks.
I also appreciate your empathy towards testers who may feel constrained by rigid testing practices. Encouraging a balance between adherence to test scripts and the flexibility to explore and discover new issues is essential for fostering innovation and continuous improvement in testing processes.
If anything is wrong with the way a team works, it’s often going to be down to the managers or persons with responsibility and power. Pushing “against” anything as a tester is a bit pointless, regardless of if as tester you are embedded in the team or are an external QA team. Some companies have done quite well by firing all testers and only hiring back testers who primarily code. Developer mindset on it’s own does not really get the code compiled/bundled and published and handle reproducing of support tickets raised by customers. Coding mindset is not an island, unless your product is code itself. In which case you don’t really need “dedicated testers”, context matters.
If you really are part of the delivery of the product, then as a QA you can get stuck between being the gatekeeper but also the person who has to get releases delivered. Roles always change. If the dev team want to do all the OPS and publishing work as well as testing, they will find 2 points of resistance, they will lack focus overall, and they will waste time, doing the process work that the QA’s in their team did for them before.
@conrad.braam I agree with the points you made. However the approach with testers who can code although being the right way forward, often leads to organisations making developers do the testing. This in turn effects the testing independence.
Moreover as QA or testing professionals we need to have our aspirations for growth addressed. This 90% of the times is not provided by the leadership team. As you rightly mentioned engineering is not about coding only, there is more to it. But the leadership team often loose the plot there.
True, but it’s not our Job as QA to tell leadership that they are wrong Mohammad . In fact we know that telling anyone about the thing you want to change takes very subversive messaging to get right anyway. I’m only lately working out how to do this too, by asking better questions, and giving lots of alternatives to every problem I bring to the table at the same time. Sure software takes having many roles, Security specialists, Creatives and Architects, let’s not forget others here.
My father always reminds me whenever I get too stressed about or too “invested” in my job. It’s a job, it owes you nothing, and you owe it nothing back, he says. Then he intones. “When you die, will your boss come to your funeral? If the answer is no, then don’t make as if it is the case.” There will always be another team somewhere in another job, who can benefit from your wisdom if it really is wisdom. It is hard, remember that those at the top will never recognise your hard work or wisdom either: Now there lived in that city a man poor but wise, and he saved the city by his wisdom. But nobody remembered that poor man.