How Do Teams Really Achieve Product Quality?
At ITHAKA, our approach to product quality extends well beyond the notion that our QA team is responsible for ensuring deficiencies are found and fixed prior to a deployment. All team members embrace ownership of quality and we see this take multiple forms across our many agile teams. Much of what we do is not new when you think about how great products are developed; however, we constantly challenge ourselves to innovate and to grow. This mindset is applicable to many aspects of our organizational culture. What stands out to me the most is how much people here truly care about quality. We strive everyday to delight our users!
Over time we have tried some things that didn’t work so well (and we have definitely learned from those experiences). We’ve also managed to get a lot of things right along the way. Let me share some examples of what has worked for our teams. Doing any one of these things alone has been a great step forward. On the other hand, building upon our successes and continuously improving has had remarkable impact.
What Does Delivering Product Quality Look Like Today?
- Every story is a deployment. Large changes break things. Our platform architecture enables us to move quickly while significantly lowering risk.
- Great story planning which includes success criteria that outline not only desired business outcomes, but also happy and unhappy path scenarios.
- QA Previews: When an engineer plans to start work on a story, a targeted discussion takes place between him/her and their QA partner to carefully discuss risks, workflows impacted and to review the Cucumber tests which have already been created. Taking this extra step furthers story understanding while preventing problems proactively.
- Test-Driven Development: Our evolution with TDD is underway. We have a few teams writing unit tests before writing story code which has proven to be quite valuable. Only writing the code necessary to get tests passing has also created another level of efficiency for us. We have established a few lucky trailblazers within the development organization to further assist other teams with adoption. Teams doing TDD have defined metrics they can leverage to continuously assess impact.
- High levels of unit test coverage across all apps and services. A story isn’t considered done without both automated unit and functional tests in place.
- Acceptance Test-Driven Development (ATDD)/Behavior-Driven Development (BDD): Teams use a test first approach which is incorporated into sprint planning, story work-shopping, coding and validation.
- Code Reviews, code reviews, code reviews!
- Backward and forward compatibility is a must.
- Our teams plan for failure so we build resiliency into each tier of our applications.
- Developers are engaged and actively participate in running and analyzing integration and functional test suite results as a part of their coding process. Recently we have seen QA working with development, enabling them to contribute to functional test creation via our Cucumber/Ruby tool set. It’s not just QA doing all of the testing—it’s truly a team effort!
- Our continuous integration/deployment pipeline enables us to deploy rapidly, learn quickly, and provide feedback to our teams within minutes or even seconds.
- Blameless Postmortems: We make mistakes and that is absolutely OK since we learn from our experiences and educate one another along the way. These lessons learned contribute directly to our success with defect prevention.
As we have gained efficiencies, the QA team has further transformed themselves into quality advocates and coaches. Broadening the role and responsibilities of each tester has been both effectual and rewarding. It has been exciting to watch the lines blur between QA and engineering over time. With each new day, we learn and adapt accordingly.
Preventing deficiencies is a very important part of our quality strategy. One important lesson we have learned is that to achieve real success, everyone on the team must play a role. I can say with certainty that none of this would be possible without such a fantastic group of product owners, designers, engineers, architects and scrum masters. Each and every team member truly values quality. All of us continuously strive to enhance our practices while working to build quality into the product instead of handling this very important aspect of product development after the fact. We don’t just talk about quality at ITHAKA—together, we make it a reality!
Have strategies for improving product quality to share? We’d love to hear from you. Drop us a comment!
