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.
Is it good enough yet? 