Thought leadership in software testing is about actively shaping processes, questioning outdated practices, and influencing team culture rather than just executing assigned tasks. It requires communicating strategically with stakeholders, coaching team members through open-ended questions, and breaking down information silos. Human judgment remains essential, especially for assessing accessibility and the subjective feel of software that AI tools cannot replicate.
Key Takeaways
- Siloed knowledge is a delivery problem: when team members withhold information or processes, the whole team slows down, regardless of individual expertise.
- AI tools can take over test case writing, but human judgment remains necessary to evaluate look, feel, and emotional experience, areas where accessibility testing depends on lived human response.
- Coaching testers means asking open-ended questions about what they want from their careers, not directing them toward a predefined path, because career shapes differ and one size does not fit all.
- Developers testing their own code introduces bias in the same way AI systems carry bias, and testers bring out-of-the-box thinking that development-focused roles do not replicate.
A tester who writes code is an engineer
Testing is engineering work, and the people who do it belong in the engineering team as full participants. Laveena Ramchandani frames it through a line from a director at her company: if you write code, you are an engineer. That sets the bar for how a tester should see their own role, not as a service function bolted onto delivery, but as part of building the product.
From there the job grows. A tester in an engineering team influences changes, shifts mindsets, and supports the people around them with what they actually need. The daily nine-to-five fills up fast, which is exactly why the harder questions get skipped.
Those harder questions are the ones that matter. Are the processes you inherited still working, or are you running them out of habit? Do your KPIs tell stakeholders something useful, or do they just exist? Stepping back to ask that is where thought leadership starts.
Why leadership in testing means working alongside the team
A title does not make you a leader. Influence does, and influence comes from working with people rather than directing them from a distance.
Laveena’s preference is to get her hands dirty and test alongside her team rather than manage from above. That choice is practical, not sentimental. When a manager tests with the team, the team sees how the work is actually done, and that is more rewarding than the typical manager posture.
The goal is to turn everyone into a thought leader, not to keep the deeper knowledge locked with the manager. A common failure mode is the manager carrying all the strategic thinking while the testers stay heads-down on routine tasks. Spreading that thinking out across the team is the work of leadership.
Lead by example when you want testers to grow
The strongest teaching tool is showing, not telling. When testers watch how you handle a difficult situation, they learn from the demonstration.
Laveena describes testers coming back to her after watching her get something done and asking what she did differently, because they had been trying the same thing for years without success. That reaction is the signal that the example landed. People are watching and learning from how you operate.
Coaching the quieter team members is slow work, and it pays off. Laveena has seen people who barely spoke up become far more communicative over time. The change shows up between the day you hired someone and where they are now.
Why getting information takes patience, not just persistence
Testers often sit at the center of a web of knowledge, which means they constantly chase information from many people. Expecting that to be quick or clean sets you up for frustration.
You will firefight a lot of people to reach one piece of information, and you may not get it at all. Reaching halfway is still progress worth keeping. Work forward from there.
Some stakeholders put a door in front of you and say they are not interested. There are ways around that door. Offer them an opportunity and frame it around the team, not yourself. Be smart about your style of talking, because the same request lands differently depending on how you make it.
Before you ask anyone anything, know your end goal. What is the main aim of the question, and who does the answer serve? When the purpose is the team rather than your own KPI line, the conversation changes.
Silos are the problem worth solving
The biggest obstacle to delivering as a team is people shielding what they know. In many tech companies, and beyond them, individuals hoard data, information, and processes.
Laveena allows that some shielding is understandable. People protect their speciality and do not want to hand it to everyone. In a team trying to deliver one thing, that instinct works against the whole.
Quality should matter to everyone on the team, so keeping knowledge to yourself only slows the group down. Being more open and more helpful lets everyone deliver faster. Hoarding does not protect you, it impedes the people you depend on.
Coach your team to ask better questions
When a tester says they cannot do something, the move is to coach the thinking, not to take over. Open-ended questions push people to reason for themselves.
Laveena’s approach when a stakeholder says no: ask the tester why they think the answer was no. That turns a dead end into a learning moment and prepares the person to handle the next one better. Be a coach, stay open-minded, and let them work toward the answer.
This matters because the alternative leaves managers permanently stuck holding all the deeper knowledge while testers run only their routine tasks. The point of coaching is to close that gap.
What you do when a person stops delivering
Sometimes coaching is not enough, and the team simply cannot depend on someone to deliver. That forces a hard judgment about whether you have the right people in place.
Laveena lived this with a supplier on a migration project. The supplier said a confident yes to handling the work, then changed the answer when the date arrived. She turned it into an opportunity and tested the migration herself, going back to work she had done twelve years earlier. Not every leader will do that, and the frustration is real.
When someone says no and it stops the team from delivering, the decision is whether to hire more people or replace the person. Those calls are emotionally heavy, because no one wants to damage a career.
“When you have to make hard decisions for the right decisions, do it. Do not feel bad. You’re doing the right thing.” — Laveena Ramchandani
Be a bit strict as a leader, and build a team of doers who hold to their commitments.
Match your management style to the person, not to another team
There is no one size fits all in how you lead testers, and copying another team’s setup onto yours will not work. Stop trying to match one team to another.
Introverts and extroverts both bring something. Laveena points to an introvert on her team who documents everything in detail, so that handing knowledge to someone else is as simple as sending a document. She admits she would not have thought of that herself. Extroverts, meanwhile, talk to managers and step into leading.
People with similar years of experience still want to drive their careers differently. Some have a clear ladder in mind, from analyst to senior to lead to manager and beyond. Others have a zigzag path because they are still figuring it out, and that is fine.
A coach’s job is to ask what the person wants from their career before guiding them. Hear their answer first, then guide. Throwing open-ended questions at them, rather than steering, lets them name their own direction.
AI changes the tester’s job, it does not end it
AI will take over parts of testing, and a large part stays distinctly human. Laveena’s response to the worry is to embrace what is coming rather than fear it, because refusing to learn it means you cannot deliver with it.
She has asked her teams to stop spending time writing test cases when AI tools can help, including tools available internally. Use them, test them, and do not blindly copy what the tool outputs. Apply your own common sense to whether the result makes sense, and use the tools strategically. AI is still learning, so you still need your own brain.
The human part is feeling. AI cannot tell you how an application feels to use, whether a website is welcoming or overwhelming, whether it has too many flashy images. In accessibility work, that emotional read is something only a person provides. AI excels in some areas and hits a wall where human judgment takes over.
Quality itself leans on that human read. Quality characteristics and KPIs all feed into a feeling of good quality, and that feeling is a human thing. The next years hold plenty of work for testers because of it.
Why a developer should not be the only tester
Relying on developers to test their own code introduces bias, the same way people worry about bias in AI. A developer checking their own work cannot see it neutrally.
Laveena makes the case for keeping dedicated testing capability, including the software developer in test who can build when you need building and test when you need testing. Some startups skip this and hire only data scientists or AI developers first, but the need for quality and testing does not disappear.
Testers think outside the box, and developers tend to stay focused on solving the problem in front of them and delivering what they were asked to build. Testers go around the bushes and try to break things, and that is where the unexpected findings come from. Be mindful of the caliber you hire, because the testing mindset is not something a development-only team replaces.
