This document discusses building a QA mindset in development teams through coaching. It emphasizes empowering teams, building trust, and using open-ended questions to facilitate discussion rather than providing direct solutions. The author advocates understanding quality risks and letting teams own problem-solving and solutions. An example shows how the author prepared for a meeting, listened to discussions, asked questions, and gave feedback without dictating outcomes. The goal is for teams to develop expertise in quality assurance through a coaching approach.

2. Building a QA Mindset
Experiences with supporting development
teams in growing within QA & test

3. Background
• Johan Hoberg
• 15 years experience in test and quality
• 10 years at Sony Mobile
• 5 years at King
• Many different roles within test and quality
• Tester
• Team lead
• Test strategy and process
• Training
• Improvement projects
• Manager

4. Takeaways
• What I consider to be an efficient way
of supporting and influencing
development teams to build a good QA
mindset
• How I have used coaching as a part of
that process

5. What is a QA mindset to me?
• Understanding quality
• Understanding complexity
• Understanding risk
• Understanding test
• Continuously improve how we build complex
high quality software efficiently

6. Working with a team
Two important factors for me when working with a team:
• The team needs to feel empowered
• They need to be able to problem solve independently
• They need to have the mandate to implement their solution
• They need to be allowed to fail and own their mistakes
• The team needs to trust me
• They need to trust that I have their best interest in mind
• And that I have no ulterior motives or agenda
• My agenda is always to support the team, and I believe the key to trust is openness
and transparency

7. Coaching vs. Expert role
• I can have a conversation with someone as an
expert and give them a solution to a problem
(expert conversation)
• Or I can have a conversation with someone as
a coach and help them build expertise to solve
these types of problems themselves (coaching
conversation)
• And sometimes it is a mix of the two
• Which you use depends on what you want to
achieve

8. Coaching
• There are many models and methods for coaching people and teams
• GROW - Goal, Reality, Obstacles, Way Forward
• CLEAR - Contracting, Listening, Exploring, Action, Review
• OSKAR - Outcome, Scale, Know-How, Affirm + Action, Review
• Etc.
• When you know the basics, you need a lot of experience to do it well
• It is critical to understand the difference between coaching someone and telling
someone what to do

9. How I approach coaching
1. Listen and observe
2. Understand the problems they face
3. Try to understand the root cause of those problems - looking below the surface
4. Explore what the situation would be like if those problems were solved
5. Ensure there is a will to solve the problems and clarify the objective of the change
6. Ask open ended questions with regards to solving the problem
7. Give feedback on proposed solutions based on my thoughts and experiences
8. Listen
9. Let them create a plan for the solution
10. Support them if they need help
11. Work iteratively

10. Example
• We made two consecutive releases which had design errors in them
• I gathered the game designers for a retrospective, and did some research about the situation
beforehand
• “This happened, and the consequences were quite severe.” (Clarification)
• “What can we do to avoid it in the future?” (Open-ended question)
• I listened to their discussions and possible solutions
• I gave some feedback
• They picked the solution they thought made the most sense and implemented it
• We haven’t had the problem since

11. Example
• A team is about to develop a new feature
• I read up as much as possible on the feature and join an early design meeting
• I listen to their discussions about software architecture and feature design
• I recapitulate what they have said, and what stakeholder expectations on quality are
(Clarification)
• I ask open-ended questions about quality risks (Open-ended questions)
• What risks do you see with this design/architecture?
• How do we mitigate those risks?
• I give some additional input on potential quality risks
• I listen to their conversation about quality risk and how to mitigate it
• I give some feedback on their plan
• They take complete ownership of the quality risks and how to mitigate them
• We iterate on this as development progresses

12. Open-ended questions
• When I ask questions I am not expecting any specific answers, I am
interested in the thought process of the individual or team
• “So what could be a good the next step?”
• “What risks and obstacles could there be?”
• “How would you solve that problem?”
• “What could be the cause of that problem?”
• “How did you reach that conclusion?”
• “What would you need to be able to take the next step towards a solution?”
• “Is there anything you can do to move this forward?”
• “What are your thoughts around this?”

13. Groups & Individuals
• I mostly work with groups of people or teams,
but sometimes it can be necessary to adapt
communication styles to individual needs
• This is mostly due to time constraints, but also
to create a sense of ownership in the team as a
whole - if I had time I would do both

14. Summary
• Create trust and empowerment to build a strong foundation
• Know the difference between expert and coaching conversations, and when to use
which
• Coaching is complex and the more experience you can get, the better
• Find a coaching format that works with the team
• You can’t tell people to adapt a certain mindset, it is a thought process they need to
go through themselves
• You are there to support them in that process

15. Final Note
The most important thing you can do as a
tester to build a good QA mindset in a
development team is to raise the right
questions, and facilitate the discussion
around them, in an open, transparent and
empowering way

16. Thank you!