It’s our responsibility as quality ambassadors to get developers to think holistically – from a user perspective, as well as positive and negative scenarios in which quality does not impact overall customer experience.
It’s straightforward. In the agile world, we need to tear down “them vs. us” silos, so every member of the team – product managers, developers, and designers – think like QA. The quality of the product should be everyone’s responsibility and not rest only on the shoulders of QA. We need to come together as ambassadors of our products to improve and move the business forward as a strong unit, and as fast as possible.
Building a quality mindset
It has always been the tester’s job to find the quality gaps in the system, and then the developer’s job to fix them when time permits, unless it’s a critical issue. Now, developers are being asked to develop and test their code. This practice has gotten mixed reviews, particularly in cases where developers don’t thoroughly test their code because they don’t have the capacity, or they’d prefer to pitch the testing over the wall to QA.
Should developers do their own testing? In my opinion, Yes! I believe it’s a myth that developers are unable to get into the tester’s mindset of destroying instead of building. Every day developers use critical thinking and problem-solving skills to develop complex systems. They should be responsible for their code and write the relevant unit tests; think like QA throughout the development lifecycle; focus on the quality, not the testing activities. No one’s code is flawless.
How do you ensure developers are thinking holistically about the application – like traditional testers and business analysts? As ambassadors, it’s our responsibility to mentor developers to think about both the positive and the negative scenarios; to think about how users will work with the system (and how they will abuse it!); to analyze the product being tested, and to look for the quality gaps.
What does success look like?
Everyone on the team, along with QA, should assist in testing the whole system. To get developers and others to think like QA, provide them with a guide that helps them recognize the signs of a “No Quality Mindset,” and offers recommendations for shifting to a process that focuses on quality and cultivates a mindset for achieving it.
| Focus Areas | Signs of No Quality Mindset | Recommendation | Success Look Like |
|---|---|---|---|
| Culture | No shared quality ownership; siloed development and quality assurance, and losing sight of the larger quality picture | Identify and define specific levels of quality involvement for individuals on teams to be aware of; enable them to share the responsibilities for them | Teams are finding problems together, and finding quality solutions together |
| Coordination | Teams are not aligned on quality priorities, and dependencies are not always clear | Prioritize testing activities for any given project and ask the team to review them with respect to the deadline (definition of done); get buy-in from all members involved | Initiative tickets guide the overall priorities and are a place where stakeholders and team members identify the quality strategy |
| Roles | Members of the team are not aware of each other or their function in the development and quality processes | Encourage team members to build out their Confluence profile: list projects they’ve worked on, areas of expertise and specialized knowledge, and hobbies. Make these a resource for getting to know colleagues | Team members’ profiles are updated with information relevant to their work and interest. Confluence is used as an onboarding tool for new employees to get to know the teams and team members |
| Communication | Lack of communication about changes to systems and features that can have downstream effects on automated testing | Think deeply about who is connected to the team and how to communicate new announcements, progress, knowledge, and more. (How we make and test things, JIRA/Confluence, Lunch and learn, Internal newsletter) | Fewer quality surprises when products and features are rolled out |
| Tools | Inconsistencies on tickets and in documentation make information unreliable; there is no confidence in them as a source of truth | Lunch-and-learns and training focused on quality, automated testing techniques, types of testing, and processes | Documentation reflects information shared between team members during the discovery and execution stages and becomes more of a source of truth |
Conclusion
Yes, QA should continue to be the gatekeepers. But the quality of the product should be the responsibility of everyone on the agile team – starting with developers who don’t even consider it an option to pitch testing activities over the wall to an isolated QA team. So begins the process of breaking down silos between development and testing.
