Quality in Testing: Everyone's Responsibility

Once upon a time, in the land of Waterfall, the business analysts wrote the requirements, the developers coded the requirements and the Testers tested the requirements. Each of these people sat in his/her ivory tower, um, silo and did that which they had always done since the beginning of time. Quality was thought to be synonymous with testing, and therefore was considered to exist solely in the Tester’s realm.

Present Day Quality

Fast forward to today, on an agile team and the barriers have been broken down – quality isn’t just the Testers’ responsibility anymore (at least it shouldn’t be). The whole team owns quality. The best agile teams have a mindset that each and every one of them is responsible for quality. There are multiple ways that quality is built in by the team. Yes, built in. It is built in from the very beginning and not just measured with testing. Testing only detects defects. Quality Assurance prevents defects, which is the ultimate goal. Teams that own quality are willing to contribute to it any way they can.

 

Building Quality in Testing Teams

Healthy relationships amongst the team are one way to build in quality. Creating healthy relationships between QA and Development will work to break down silos between the two groups. Testers can look to ScrumMasters for advice and input. They can look to Product Owners to give and receive feedback on Acceptance Criteria, or provide feedback on test cases and defects. The end result of all of these relationships will build in quality in testing teams.

Opportunistic pairing is another technique for building in quality. The pairing could be Developer with Developer, Tester with Tester, Developer with Tester or even the Three amigos (Developer, Tester and Product Owner). Pairing reduces or eliminates the need for post-implementation code reviews and rework in many cases. At the very least, each person will get visibility into the other person’s tasks and thought processes.

With healthy relationships comes the ability or comfort questioning and even disagreeing with team members. Sometimes this means features need to be redesigned around testability. Sometimes this means testers need to shift on what they think the most important tests are. Sometimes it means the team takes a calculated risk around what will be validated and what won’t be validated. The key is understanding the risk and discussing, as a team, what tests are important for today, for the week, and for the sprint. It is the “right” just enough. By engaging everyone in the conversation the team helps shift more toward the idea that quality is everyone’s responsibility.

Wrapping Up

Quality in testing is everyone’s responsibility. We need to break free of associating team members with a particular silo. We need to stop thinking in terms of “Dev Complete” and “Test Complete”. There is one team, and together that team can build in quality. Build in quality everywhere and every time that you can. Break down barriers, facilitate healthy relationships, and encourage communication. “Be” agile and make a mindset of quality the norm for your team.

 

Up next:

• A Case for Quality… We Don’t Need No Stinkin’ QA >> Read
• The Real Reason we Test >> Read