In the previous post I’ve listed some responsibilities of the Quality Coach role. One activity I’ve performed to meet those goals was running with a team – joining a development team for 1-2 months to produce high quality results together, and to build quality into the product. 

As an experienced software tester, this was the quality coaching activity which felt most familiar and comfortable for me. I worked as part of an agile team to develop acceptance criteria, and helped guide the team on creating a test strategy and approach to suit their project. We used Atlassian’s quality assistance model as a starting point and adapted the process over time to meet our needs.

QA Kickoff

For individual stories I would attend a QA Kickoff meeting to map out test scenarios with the developer and product manager. During the meeting I’d ask a lot of questions, and together we would consider risks, probe edge cases to help determine scope, and consider various relevant aspects of software quality. Most of the mind map contents were generated together during meetings so that sessions were more collaborative and creative, to encourage thought and input from different perspectives. 

Initially when running with a new team I’d try to ask specific, leading questions during the QA Kickoff, similar to the questions asked by testers. Then over time I would slowly switch to coaching mode, asking broader questions to promote a longer-lasting quality mindset.

Software Testing Questions	Quality Coaching Questions
What will happen if 2+ users click this button at the same time?	Do you have any concerns around concurrency? Together, can we review the tests which cover these risks?
Will data integrity be maintained if this process is interrupted?	Are there any risks to data integrity? How are they being mitigated/prevented?
Which file types are unsupported? Is an error displayed when an unsupported file is selected? Should the error message contain more details?	What can go wrong? How will the user know something is wrong? Will they have enough information to fix the issue?
I’ve added a UI automation test for this bug.	How can we prevent this type of bug from reoccurring?

The software testing questions remind me of coaching sessions with junior testers in past roles. By asking specific questions, you’re leading them towards a quality risk area which you’ve already identified. The quality coaching questions remind me of reviewing a test plan prepared by a senior tester. You ask more open questions and then work out the answers while learning together.  

Unlike a software tester, the quality coach then relies on the developer to perform the actual testing and provide answers to the questions raised during the QA Kickoff meeting.

QA Review

For faster feedback loops, the developer should test their own changes prior to the QA Review. These meetings can also include a product manager, a senior/peer developer and a designer. The developer demonstrates that all scenarios from the QA Kickoff have been covered, and explains any changes made to scope/functionality since the QA Kickoff meeting. The quality coach can provide coaching during the session, usually in relation to test coverage gaps and automation test code patterns. 

I’ve found these sessions to be effective in helping developers shift perspective from the lines of code back to the user experience, and to look at the bigger picture.

But “developers can’t test their own work“, can they?

To be blunt, developers being unable to test their own work is a fallacy that has suited the software testing industry very well. It has also been a convenient theory for those software developers who prefer to let someone else do their testing for them. My own opinion on this has changed in recent years, and it’s sheer luck if I don’t have a poorly-aged blog post stating that developers can’t test their own code.

I’ve seen that the best developers can and do test their own work. In an unhealthy culture, those developers can be viewed by their peers as slow and less productive, despite having better code quality and less bugs found by testers, and therefore less rework required. In those unhealthy environments, the testers and engineering managers have different ideas about which developers are the more valuable and productive members of the team. Senior testers, when paired with developers who test their own code, are able to adopt more of a quality coaching mindset and help the developer improve their own testing skills and code quality.

Quality coaching mindset

Developers on your team may be used to working with testers and be uncertain of what quality coaching means for them. It helps to clearly describe and demonstrate what quality coaching involves, and specifically what it doesn’t include – i.e. testing their changes for them.

Having a quality coach work with the same team for too long can blur the lines between quality coach and software tester. I found that by changing teams regularly, it reinforced the message that the whole team is responsible for quality. It also reminded me to act as a quality coach, especially at times when I was tempted to jump in and do some testing myself. It encourages a subtle focus shift from having product quality as the only goal, to helping the team reduce their feedback loops and independently produce quality software.

Knowing that there are no testers in the team, and that the quality coach will be back on the team again in a few months, hopefully helps to encourage a lasting quality mindset amongst the developers in the team. 

This is Part 3 in a short series of posts about quality coaching. The next posts describe some additional activities performed by a Quality Coach.