My name is Deb Sherwood, and I am a Quality Coach at Squiz. I have been at Squiz for nearly 17 years, starting as a trainer and moving into the engineering team as a software tester. Before joining Squiz, I was a software engineer working in an environment where we had thousands upon thousands of automated tests!

As a trainer, I got to experience first-hand what it was like to use our product for the first time, and I saw how many different ways a user could use the system to achieve the same things. I lived through the pain of learning something new and the joy when it worked. This experience made me passionate about wanting to produce high-quality products for our customers that meet their expectations.

Currently, the engineering team has 45 software and devops engineers…and one quality coach - me! Trying to help this many engineers can be overwhelming. Still, since transitioning from a quality engineer into a quality coach three years ago, I have worked out ways to keep an eye on quality and help the teams without going crazy!  

This is how I make it work.

45 Engineers and 1 Quality Coach - How do you make it work?

As professionals working in the quality space, we are asked to ensure that the products the teams are building meet a certain level of quality. We generally do this by having a team of people who can embed themselves into an engineering team so that they can educate everyone on what good looks like. We do this knowing we empower them to take on the responsibility for quality for their part of the system.

But what happens if the quality team is a team of one - you? How do you ensure all teams reach a certain level of quality with the services they are building without splitting yourself into ten different pieces? How do you make sure engineers know what good looks like?

As one quality coach to 10 product teams, I have to ensure quality is everyone’s responsibility and help teams understand there is no one person in charge of quality. Based on this, here are my five top tips on what to do when coaching a large number of teams

Top 5 Quality Coaching Tips

Encourage everyone to test from the start

You want to encourage teams to test as early as possible, from when an idea is formed to when it hits production. The earlier they test, the earlier any defects found are cheaper to fix. If you wait until the task is in the validation phase, any defects found could be very time-consuming and costly to fix, especially if it has to go back to the design team to re-do the interfaces.

Write, write, write!

Write anything you are trying to communicate on “a piece of paper” (e.g. in a Slack message, on a Confluence page, in a Googe Doc). Write down the recommended practices, suggestions, how to test features, when to perform different types of testing, and anything that seems necessary. That way, not only can it be shared with existing team members, but it can be shared with anyone new starting at the company.

This is probably one of the easiest ways to spread the word when working independently.

But remember, things can change, and what you want teams to do can also vary, so make sure to periodically review what you have written!

Help with the refinement of the more significant, more complex features.

Being a “team of one”, you can’t be at every refinement or planning session, standup, retro or workshop for every feature for every team. All you would do is attend meetings! So instead, look ahead at what initiatives are being planned for in the coming months and aim to help teams with features requiring many changes to the product. These more significant, more complex features will potentially have a lot of unknowns for the team, especially if they are making changes to systems they may not have built themselves.

If you sense there is any doubt around the changes required during the refinement sessions or there are unknowns, encourage the team to take time to investigate it further with spikes or proof of concepts. It is better to spend time investigating unknowns before you embark on changes than to get halfway through and realise you need to build it differently.

Pair Testing

Pair testing is the quickest, easiest way to educate engineers, especially junior engineers with less experience, on what “good” looks like. You can spend hours talking to engineers about testing but showing them real-life examples is how people learn. As a “team of one”, I don’t actively look for pair testing opportunities. Instead, I let them come to me. If an engineer approaches me with questions such as how many tests do I have to write? What should I test for with this piece of code? What should I do when validating a user interface? or if I get a sense of them being not so confident in what tests they have done so far, I ask them to show me exactly what they are testing and start talking through what we need to test.  

Over time, you will find that the engineer will start learning what they need to look for when testing and won’t rely on you as much to help. Also, sharing your knowledge with the engineers through pair testing ensures that everyone knows what quality is expected. As a result, you don’t have to worry as much about having to know everything that is going on. Instead, you are empowering the team to be responsible for the quality of their service.

Talk, listen and support

When you are only a team of one, people may think you are busy and won’t ask you for help. They may keep things to themselves so as not to burden you. Quality coaches need to be proactive with your listening skills. Take time out now and then to talk to people with whom you don’t currently work every day. Just by taking some time to talk to these people, you may identify issues you didn’t know about.

For example, I recently chatted with a group of new engineers who had joined our team working on one of our legacy products. I noticed these engineers were quiet during the planning and refinement sessions. Their lack of knowledge made it hard for them to ask questions. But, learning a legacy system is difficult; it will take time for new engineers to become confident in these systems, and asking questions in these sessions helps build up knowledge. Not only will they learn a bit more about the product through the answer, but the questions themselves often reveal previous assumptions with critical information missing from the acceptance criteria.

With this information, the feature could be correctly built, and the product quality would not be impacted. If I had not chatted with this group, I wouldn’t have known this was an issue.

So remember to take time out to keep in touch with people you are not actively working with. You never know what you will find out!

And that rounds out my top 5 tips for people embarking on this journey. Do you have any tip suggestions to add to this list?