The SQA2 Blog: General
Someone on your QA vendor’s team will leave your account at some point this year. They might get a promotion, a move to a bigger client, a job somewhere else. Every account goes through it. It’s normal.
What matters is what happens next.
When that person leaves most vendors, much of what they knew about supporting your system goes out the door with them. The testing environments, the edge cases, the bugs they’d seen before, the way your team prefers to work—all of it lived in their head. Your engineers then lose the next month or two bringing a new person up to speed, and any bugs that slip through in the meantime are an inherent problem to this occurrence.
I wrote about what that costs in QA Continuity Is an Asset. This one covers how we avoid it.
You’re working with a team, not one person
A client who works with us gets a Quality Engineer embedded on their team, and behind that person stands our entire Software Quality as a Service (SQaaS) organization. We’ve set things up so that no client depends on any single individual.
That’s on purpose. Whether someone on your account moves to a different project, goes on leave, or leaves the company, your account should keep running the same way.
It comes down to documentation, and how seriously we take it.
How the knowledge is separated
There are two kinds of knowledge, and we deliberately keep them separate.
The first is the client’s own knowledge repository. Anything specific to the client’s system stays there, on the client’s side. It serves as the working record of what the team has learned while supporting the system, and in every engagement, keeping it current is one of the most important things we do. It’s also one of the first places a new authorized team member starts when they join the account.
What’s often most valuable in a client’s knowledge repository is what only years on an account can produce: what normal looks like from a testing perspective, which issues have come up before and how they were handled, and the testing practices the team has learned work well. When someone leaves, that’s usually the knowledge that walks out the door.
Each client’s security, confidentiality, and access requirements govern what belongs in that repository and where it is maintained.
The second is ours. SQA² maintains the operational QA knowledge needed to support continuity on an account: how the engagement works, how we deliver on it, and what a new team member needs to know to get started. Preserving continuity doesn’t require us to duplicate the client’s system knowledge.
Three things set this apart from what most vendors call documentation:
- It’s written for the next person. A new authorized team member joining the engagement should be able to use it without having to rediscover what the previous person already learned.
- It captures the things you only learn by working with the system over time, like whether an issue resembles something the team has already seen, what normal looks like from a testing perspective, and which testing approaches have proven effective. If that knowledge is lost, it can take months to build back up.
- It belongs to the client. It’s not someone’s personal notes. It’s part of the client’s own institutional QA knowledge, maintained on their side and available according to their access and security requirements.
How it stays up to date
Documentation only helps if it’s current. An entry that was right a year ago can send a new person down the wrong path.
The SQaaS team supporting each account reviews and updates the client’s knowledge repository twice a week, in what we call Knowledge Quality sessions. Knowledge Quality is one of the pillars of QA 2.0, and every Quality Engineer is trained on it from their first week.
Documentation is busy work at most vendors. That’s why it never gets done. Documentation is the first thing dropped when a release needs support or a test run isn’t finished, and there’s always a release that needs support. For the same reason, many of the teams we work with have little documentation of their own, because their teams are too busy shipping to write things down.
We train our new team members on the critical importance of these sessions. It can feel like busy work. It take an hour away from things that feel more urgent. We also train them that the hour will get spent either way. Skip it now, and the next person spends it, and more, learning everything from scratch
Again, these sessions are possible because of our SQaaS organization. The embedded team keeps delivering while SQaaS helps maintain the client’s QA knowledge. Documentation and the release never become a choice the client has to make.
And our team isn’t the only beneficiary. The client’s own engineers end up with a current record of the QA knowledge developed through the engagement—one that helps their internal team as much as it helps ours. Time their team may once have seen as busy work becomes an investment in an asset they own.
Knowledge returning home
Client relationships don’t stay one size over the long term. A big program wraps up and the team gets smaller. A quiet stretch means one person instead of three. Six months later, a new project needs the full team back. Same client, different project.
At most vendors, each of those changes costs you someone with experience supporting your system. When the team shrinks, the person who leaves your account goes to another client. Grow the team again and you get someone new who has to start from the beginning.
A team member who finishes an embedded assignment comes back to SQA² as part of the SQaaS organization. Before they transition, we make sure the QA knowledge they developed through the engagement has been captured in the client’s repository. The experience they gained continues with them as they keep working within our SQaaS organization.
We call this knowledge returning home. Two things become possible because of it.
Growing the team again. Whether you need people back six months or two years later, the client’s QA knowledge is still there, and SQA² still has people with experience supporting the engagement. That’s how we’ve been able to add people to an account we’ve supported for many years who already have experience with a client’s platform.
Replacing someone without starting over. If your Quality Engineer leaves the account for any reason, their replacement isn’t starting from zero. Once authorized, they have the client’s documented QA knowledge available to them, along with an SQA² organization that understands how the engagement operates.
What this looks like on a real account
One of our clients has been with us for more than twelve years. Recently they asked how soon we could add two Quality Engineers to the account. We had both of them available the same week.
Within a few days of getting access, both were picking up work and supporting releases. Typically, for other QA vendors, that’s not normal. A new person on most accounts spends their first month asking questions, waiting on answers, and learning by making mistakes. Here’s why it went differently.
Neither of them was starting cold. Both had supported the account from the SQaaS side before they were embedded, so they already had experience with the engagement. Once the appropriate access was provided, the account lead walked them through the client’s knowledge repository.
They went in already understanding how the team works, the testing practices used on the account, what normal looks like from a QA perspective, and the kinds of issues the team had encountered before.
Years of Knowledge Quality sessions had kept that knowledge repository current, because maintaining it had been an important part of the engagement. The lessons that mattered for future QA work weren’t dependent on one person remembering them.
Backup was there too. Other SQA² team members had previous experience supporting the account. When a question came up that the knowledge repository didn’t answer, there was someone with relevant experience to ask.
When that happens, the gap doesn’t stay a gap. A ticket gets created for it, and it becomes an item to address during a Knowledge Quality session. The next person who joins the account won’t have to ask the same question.
That’s the model working. The client needed two people fast, and we had two people who weren’t starting from zero because they had already supported the engagement through our SQaaS organization. The client’s QA knowledge was current, the experience was there, and there was a team behind them.
Twelve years on the account showed up in their first week.
Ask your vendor
So ask them. Where does the QA knowledge about my system live? Who else has experience supporting my account? If the person on my account left next month, what would the replacement have available on day one?
A vendor who has a real answer will show you. If they don’t, that’s your answer.
If you want to put a number on it, the QA Vendor Continuity Score takes about two minutes.
This is part of our work on QA continuity.
