RSS

Tag Archives: Quality Coach

The Role of a Quality Coach

Context 

For eight months I’ve worked with software development teams in the role of senior quality coach. We work in agile teams, without ever using the word agile. Most teams include software developers, a product designer, a product manager and an engineering manager. There are no testers or business analysts, and everyone on the team can write code to some degree. 

Quality coaching is not software testing

Quality coaches do not fill the role of software testers. While it’s commonly said that each person in an agile team owns quality, this truth can be undermined by the presence of a tester in the team.*

To state it more clearly: quality coaches do not own the test strategy, automation test suites, build pipelines, lists of defects, test environments, or test data. Quality coaches are not responsible for investigating failed test results, performing exploratory testing, or writing up bug reports. 

Every one of these artefacts and activities is owned and maintained by the development teams. 

Quality Coach Responsibilities

Create and promote a quality mindset within the team. 

Work with stakeholders to discover/determine quality goals. 

Explore the product to gain context. 

Provide coaching, guidance and training on software quality and testing.  

Collaborate with other teams including Support, Sales and Marketing to better understand user goals and behaviours.

Stay curious, ask questions, follow up on loose threads. 

Help facilitate risk workshops, bug bashes, post-mortems and other brainstorming sessions.

Advocate for process improvements.

This is Part 2 in a short series of posts about quality coaching. The next posts elaborate on the activities performed by a Quality Coach. 

*Embedding a tester in an agile team can work very well, for example when the bulk of testing is performed while pairing with the developer who wrote the code.

 
Leave a comment

Posted by on July 11, 2021 in Software Testing

 

Tags:

Coaching Testers vs. Developers

After many years leading and coaching testers, for the past 6 months I’ve been working with developers as a quality coach. I’m keen to share lessons learned from my experience so far and to learn from others working in Quality Assistance and Quality Coaching roles.

What’s different?

Enthusiasm

Testers are eager to learn more about testing, it’s their passion. The “pull method” of providing coaching and training on demand worked very well, where I made it known that I’m available to the team and they approached me to arrange sessions. Testers reached out to ask for advice, and I was invited to meetings, asked to consult or collaborate, or asked to review work. In some cases my reputation in the testing community has preceded me to a new role, and testers were keen to collaborate from the moment I joined the company.

Great developers are also open to learning more about testing, but the word ‘enthusiastic’ doesn’t spring to mind. If I was to rely solely on the pull method of waiting to be asked for coaching, I would have a lot of spare time on my hands. Instead I attend standup meetings, planning sessions and retros, and I look for opportunities to propose coaching and pairing sessions. It requires me to be more confident and assertive, and somewhat persistent. It’s fair to say that my reputation doesn’t precede me with developers!

Arranging the first session with each developer is the biggest hurdle. The quality assistance/coaching model is relatively new for most people, and there’s uncertainty around what will be involved. As with most things, it gets easier each time.

Training method

For a team of testers, I could present three new concepts in three weeks. For example: mind-mapping test scenarios, focus/defocus exploratory testing technique, and consistency heuristics. Testers love learning these techniques, and incorporating them into their regular work. I picture them adding new tools to their toolbox, to help them find quality issues more efficiently and effectively. The value and usage of each new tool is self-apparent, meaning it’s obvious to the testers where and when each new concept will be useful.

Working with developers, any coaching on testing methods will be more successful if demonstrated and proven in the context of the code/feature/product they’re currently working on. I’ve found that I’m not able to update and reuse my existing presentations and materials which are theory-based and use practise testing websites. It’s almost as though the method you’re demonstrating needs to find a bug in your own product during the training session, to be considered a technique worth learning. I picture developers with a small extra toolbox for testing that’s already full, and they’re not convinced yet they need to purchase a larger toolbox!

My own expertise

When doing one-on-one coaching I learn new things every single time, such as domain knowledge, keyboard shortcuts, useful browser extensions, etc. Even so, I’m typically guiding more than I am learning.

While coaching developers it feels more like a two-way learning process. While asking leading questions about quality, scope, and risk, I’m also learning about the operating environment, debugging methods, code structure, in-house test tools, and more. Importantly, I’m seeing how many bugs can be traced back to code patterns and structure, and can therefore be prevented at that level during development. It’s exciting to learn new ways of preventing issues rather than detecting them later.

Which is better?

When I’m working with testers I automatically assume the role of mentor, trainer, leader. For years this has been my comfort zone – testers are my tribe, my people, my community. Personally and professionally, I thrive when I’m just outside my comfort zone. In the past that has lead me to pursue consulting, contracting, senior management roles, public speaking, organising meetups, hosting training courses… Now taking on this new role has allowed me to use my experience in the software industry with quality and coaching, while pushing me to learn about development more deeply.

I’m hopeful that by coaching developers I can have a greater impact on preventing/reducing product quality issues and therefore help to produce quality software faster. It’s still early days.

Please reach out if you’re also in a Quality Coach role and would like to share notes.

Part 1 in a short series of posts about Quality Coaching.

 
Leave a comment

Posted by on June 13, 2021 in Coaching, Growth, Learning, Quality

 

Tags: , , , ,

 
%d bloggers like this: