Experience Report: Introducing Change To An Organisation As A Test Consultant

By Beren Van Daele

Our story starts with a woman in search of answers. Answers that will help her succeed in the next phase of her professional career: Becoming a successful Test Consultant.

After having led a team of testers for several years she felt ready to meet other companies who could benefit from her expertise. Her new path’s first assignment involved introducing a new tool into an important client’s company. However, it was immediately clear to her that the tool wasn’t going to fix their problem, they needed a refocus. She felt that they needed to change their ways, their strategy. She was nervous about her next move. She wanted to know how to do a good job, keep her employer content and look for a way to measure her success.

She was balancing the distinct line of keeping different stakeholders happy.

Her employer wanted to sell a new tool and hire her out as a change consultant for said tool.
Her client wanted their problem to be solved and thought the tool would be the way to do so.
She wanted to help the client earnestly and do so on her own terms, with her own insights.

Three different actors, three different expectations. Her task was to find a balance.
She knew she could do it, she had the know-how, the skills, and the personality to get things done.

Yet, three questions burdened her:

  • How can I help bring the change they need?
  • How do I know the change was caused by me?  
  • How can I be sure that the client needs me?

She reached out for advice and this is how I came to know her story. I tried to formulate an answer from my own experiences and observations.

Bringing The Change The Organisation Needs

While there are always opportunities for supporting the client, and problems to solve, in my experience real, lasting change is very hard to come by. We can’t expect people to blindly follow our advice, support us in the direction we want the client to go in and further yet, persist that change when we have left. Au contraire, I distrust anyone who would lead you to believe they have all the answers. Nurturing change is hard. Bringing in a new tool is easier, probably more profitable at first, but in the long run, your client might have wanted you to employ a more personal approach with your expertise.

Being A Consultant in Software Testing

Being a young Software test consultant has been a lonely path for me. I am an outsider. I have been used and misused. Sometimes I was able to see the ulterior motives beforehand and sometimes I didn’t and failed.
Due to the temporary nature of the assignments and the amount of distrust for so-called experts, we have to consider tactics which may work in certain situations and which ones may not.

I often find myself going home after a day’s work disillusioned or frustrated. This happens mostly when I find myself in a situation where I’ve worked hard supporting the team by taking up responsibilities or tasks that shouldn’t fall on me but are too important to ignore, only to see this being met with the exact opposite of what I wanted to achieve.

An Occasion Of Learning

One such occasion I had been functioning as a liaison between Business and the Software Development Team. I was deflecting nonsensical change requests, helping to keep priorities straight, stressing the importance of a good demo and chasing after important information. These tasks were being neglected by the team and resulted in more confusion and workload for the team. I tried to fix it.

Conflict With Direction

Several weeks later, I signalled to the team that we might need another software tester to tackle all these new tasks and maintain good testing efforts. Several people turned quite hostile at the suggestion.

I argued that capturing, training and supporting the business users were emerging tasks that were laid bare through constant communication through Jira tickets, which is a suboptimal way of working together already. I wanted extra time, resources or help to deal with this and that if this wasn’t supplied, our testing work would suffer from having to deal with those new tasks.

Arguments & Fallout

Instead of listening to my arguments and helping me, the loudest voices on the team told us not to communicate with the business side, not help schedule releases, or discuss bugs found by business testers. We were all contractors at the time under management of an internal project manager, supported by internal functional analysts. All of these were not really considered part of the team. Therefore, the team operated mostly on a “not our problem” mode when it came to dealing with issues raised by anyone who wasn’t speaking from a position of power.

When I challenged the team to think about increasing efforts to support our users more and broaden our tasks further, it was met with reluctance. They told me to stop. They escalated to project management that they should deal with their user feedback.


Basically, I was told to mind my own business, which was testing. Testing in the narrow sense. Testing, as in verifying whether the developed stories actually work.

Just like that, a whole lot of good things broke.
Because from that point on, I had to start anew. This forced me to change tactics.


Weeks later, our backlog filled up with requests from users that made no sense, that were misunderstood by project management and supposed-to-be-issues that were solved by training.
Things I had been deflecting for weeks now found them in our backlog, wasting everyone’s time.

Seeing these new problems arise and the pain they caused, which came from me not doing those tasks anymore, I tried to change in different ways than escalating. Asking for more resources didn’t work.

Change Without Asking

Sometimes you need to make the issues more visible instead of presenting a solution. The following are some of the things I did to create visibility and “voice” my frustrations without asking.

  • I worked to give these bogus issues more visible by adding tags to them and put these numbers on our dashboard.
  • When we discussed such issues in meetings and then abandoned them as unclear or ‘not an issue’, I pointed out how many people spent time on this task.
  • The moments that a developer asked me to explain some user feedback to them, I would show them how this was a misunderstanding.
  • I would triage a list of issues weekly with project management and redirect them to users with additional questions.
  • Sometimes, I’d play dumb and blindly forwarding time-wasting tickets, as I was told to do. Even if it made me feel bad.

Visibility & Responsibility

Real pain, actual numbers, and lots of small moments gave the issue more visibility than me pointing it out in the first place. Now it wasn’t only my pain or responsibility. It was everyone else’s.

They came up with tactics and processes to achieve what I wanted all along: A better relationship between business and development resulting in better quality.

  • Teams would assign a support role in their team that would rotate.
  • They would have triage meetings with project management and the functional analysts.
  • We’d work together on training documents during development.

After some painful weeks, the team was well underway to have a close-knit relationship with our users and have straightforward, flexible way of implementing change in accordance with their feedback. Due to external circumstances, the project kind of imploded and we never saw it come to fruition.

Sometimes, You Get What You Need

Looking back, I realise I didn’t get what I asked for, which was more people. Neither did the loudest voices get what they wanted, to put the responsibility solely with the internal people. Eventually, by allowing and creating visibility and letting the pain be felt, we got what we needed. A whole team focused on dealing with issues and working closely with business. From that experience on, I’ve been trying to introduce change without being perceived as changing anything.

I have a few success stories on that... and a couple failures as well.

The Cause Of Change In An Organisation

You can’t know for certain whether the change manifested because of you and it shouldn’t be important. I talk to people and tell them stories, explain to them concepts they don't know, talk about possibilities, give them a book, or a blogpost... a nudge here, a nudge there. Sometimes people act on them, sometimes they come up with something completely different that works just as well.

I'm usually only creating space/time/energy/motivation for people to do this.


"Hey Product Owner, many people on the team don't know which projects are due when and have a hard time focusing on specific projects, wouldn't it be great if we had a visual timeline of a high-level planning somewhere?"

She didn’t realize the team was confused by the many projects and deadlines. After we talked about what a solution might look like, she went ahead and created a huge, visible timeline on the main wall. It helped the team keep an overview of what was happening when and make decisions related to the timeline. I didn't take any credit, I’m not even sure the PO remembers me advising her in that direction. Yet, I saw the value and felt proud nonetheless.

In my experience, being a software testing consultant isn't going to get you much glory. Nor should it. It shouldn’t be about you. It should be about helping people and teams get better. You usually can’t nurture a team to become better by being a hero or a commander.

To me, seeing change for the better is worth more than being perceived as the bringer of it.

Different Tactics To Introduce Change

At TestBash Manchester 2016, I talked about a project that was dysfunctional from the get-go. The goal was a complete revamp of the IT department into a more modern technology stack and using newer, fancier processes and tools.

This company wanted to drop the braces, get a new haircut, fancy clothes and a new hobby so it could hang out with the cool kids again. It hired a bunch of these ‘cool kids’ to show them the way.

Consultants. Lots of consultants. In one month’s time, they showed this company the way of SCRUM, Agile, TFS (an Application Lifecycle Management tool), a brand new release process, sticky notes on boards, .NET instead of Progress and much, much more.

If there was ever an environment to introduce lasting change, it was there.
With so many consultants in one place with ‘change’ as their main goal, I found it very educational to observe all their different tactics. Seeing all this bustling from up close, I was able to identify several different tactics to induce change. You may know them under different names or slightly different shapes.

Strong-Arm Tactics

One such tactic I found is the most straightforward, bullheaded way of introducing change: You tell people to.

The person I’ve seen this done effectively wasn’t the most inspirational, knowledgeable or diplomatic of the consultants. But they radiated an air of authority, were cunning, stubborn and often balanced on the line between argument and bullying.

They had a will to get their solution no matter what.

You might mistake my description as something severely negative, and strong-arming could be seen as something you should try to avoid at all cost. In truth, it can be incredibly effective on the short term. Your change may not last the longest, as you won’t have much buy-in from your client. When you turn your back or leave, chances are things will revert back to where things were. Even if initially, you see results pretty fast.

Much like choosing which test technique to use when it’s important to be mindful which change tactic to employ in different situations. These are some pros and cons can help you make those decisions:


  • Quick results.
  • Needs less emotional investment.
  • Actor may be seen as a leader with authority.


  • Overstep your game and it may also lead to a swift exit.
  • Needs a certain personality to pull off.
  • Make silent enemies.

Consulting Streetcred

Another of my colleagues was a renowned project management consultant who had an impressive portfolio of experiences, clients, and credentials. Much of what they said was taken at face value. Most improvements came from them and they paved the way for us to do the same.

While they were immensely helpful to me and the rest of the team, we didn’t always agree on what the correct solution would look like. Because of their position they, and the people around them, would assume their solution was the best. This sometimes worked in a counterproductive way.

What they missed, by not always listening, they more than made up with quick and strong advice. It was more important to have answers than to be able to explain why or question their approach for them. That’s what made them look like the expert in the first few days and what will keep them credible for the remainder of the project.

For each and every project, with a few exceptions, your credibility has to be earned through hard work, earning trust, and by providing good solutions. Having an impressive background will only help so much.

My reputation, experience, and certifications alone will not convince people I know what I’m talking about. Without wanting to overestimate myself, I’ve been studying the testing field quite a bit, but I still have people tell me what my job should be.

Sometimes, even multiple times on the same project, credibility will have to be built time and again. It can be disheartening, but I find the reward to be well worth it.

Building up credibility needs time. It’s a fickle thing that can suddenly soar or plummet for various reasons. Sometimes you speak up too late, sometimes you overshoot, and other times your ideas fail miserably. Be mindful of when you can depend on your credibility and when it is harmful. You want to make sure you can balance your input verses encouraging and growing the internal talent to a higher level.


  • Quick results.
  • Needs very low investment once credibility is built up.
  • Actor may be seen as a leader with ‘all the answers’.


  • You may suffer from the hero complex.
  • You may expect people to follow you based on past achievements and not merit.
  • People may not value your accomplishments as much as you want.


Some extraordinary people with incredibly broad, and in-depth, experience in our field are able to use pure logic to be the driving force for change. They’ve seen software development from the inside and outside. They’ve been a programmer, tester, analyst, lead, manager and have a very good idea of what problem to change first.

Imagine an old and wintered engineer who’s able to explain the most complex issues in a clear and seemingly simple manner. They use metaphors and descriptive language to shape the solution as if it’s right in front of you.

On the other hand, there are consultants who use a certain official process, methodology, or set of ‘best practices’ to tell people where they should be heading. They sell a ‘tested and proven’ approach that will solve whatever problems a team may have.

My advice: beware of those people. My plea: don’t become one of those people.


  • People act because they see the problem and solution clearly, not because you told them to. Intrinsic motivation is a powerful thing to be able to trigger.
  • Actor is seen as a trustworthy expert.


  • Clear communication without the appearance of seeming smug or conceited is a difficult skill to master.
  • People don’t necessarily respond to logic.

Plant Seeds of Change, Watch Them Grow

My favourite way of introducing change is by planting ideas in people’s minds and have them come up with a solution by themselves.

I usually don’t like talking about generic things. When I talk to coworkers I ask them about what they are doing, what their problems are, and what they want to achieve, not which car they want to buy. By really listening to what their challenges are I’m able to connect ideas. Two individuals complaining about the same thing is very different from two people with a common goal.

I try to find those opportunities, connect the two, and extend a hand. Sometimes they take my idea, sometimes they come up with their own. What’s certain is that those two people have a better chance at introducing change than I would alone.


  • People act because they see the problem and are motivated to solve it.
  • The people take ownership of the change which they want to see.


  • Takes a long time to accomplish.
  • Heavy emotional investment.

Influencing & Client Needs

Looking back at each of these approaches, most of them foster change inside other people. The influenced people will bring the change, not you. The same way as quality is improved due to our testing role without actually changing any code, a consultant brings change and improvement, not by changing things themselves, but by helping people see more than they did before.

Knowing this, you need exceptional communication skills and/or a keen observer as a client to have those small changes attributed to your presence. Lastly, only one question remains:

How do I know the client needs me?

The client doesn’t need you, honestly. Not usually. Projects go on and are successful without you. We can only guess at our exact value or our perceived value. But that’s not our main goal. We want to give the client a better chance of improving their situation, their team, their projects and increasing their chances of success.

However, I’m positive that I can be a productive addition to almost any team that’s open to having me work with them. I’ve earned my confidence through versatility, quick learning, and being a student of my craft. I know my weak spots and my strong suits. I can help them discover the same things about their projects.

You can become more confident in your skills too. Usually, you're hired based on your performance during a short interview. Being confident in your abilities, in combination with your enthusiasm, and manner of interaction, will help to show, even during as short a timespan as an interview, you can have an impact.

When people contact me afterwards telling me about all the improvements they eventually made, it makes me exceptionally proud and happy. I like to believe I'm not needed. And if I am, I work towards coaching people to make sure I become unneeded.

I did get an email from the aforementioned PO which ended in: "We weren't ready for you a year ago." Since I left, they’ve been consistently following the path of improvement and change that I, partly, laid out for them. They apparently attribute a big part of that to me. A bigger sense of accomplishment than I have yet to find. This showed me the value of my work there. Years later, I find out I did something right.

To The Starting Software Testing Consultant

Don’t be too worried about being perceived as the bringer of change. Learn about operating in complex situations, getting great tools under your belt, and start training in making yourself understood. Most of all, grow a thick skin and find the wonderful glory in seeing others succeed.

Author Bio:

Beren Van Daele

I'm a software tester from Belgium who helps shape teams and testers to improve their work and their understanding of testing. I'm an organizer of BREWT: the Belgian Peer conference & a test meetup in my hometown: Ghent. The creative brain behind TestSphere and a speaker at TestBash Manchester and Eurostar 2016. My dream is to become a test coach for people nobody believes in any more or no longer believe in themselves. People who have the motivation and will, but no luck. I want to tap into that potential and give them the opportunity to become awesome testers.