I attended SATURN 2015 in Baltimore and presented a talk with my colleague Rebecca Wirfs-Brock on looking at how agile organizations can include quality as part of their mindset. I’ve been working on this area for quite a few years and have been actively writing and working with organizations teaching and mentoring in thie area. Rebecca and I are committed to changing the standard mindset where some of these core principles can get overlooked or put off in many agile teams. We’ve both presented workshops and I’m looking forward to our presentation at SATURN.
It was exciting to hear that Rebecca and I won the New Directions award for our talk on this topic while at SATURN. The following is from one of the papers we’ve written on the topic.
As organizations transition to agile processes, the role of Quality Assurance (QA) needs to evolve. Nothing prevents QA from being involved throughout the development process, but often this does not happen. Unfortunately, many QA people only become involved late in the development process, just before it was necessary to test and release the final product. This has been so primarily because of a different mindset between QA in traditional software processes and Agile QA. Generally, QA’s primary responsibility is to certify the functionality of the application based upon the contract and requirements; usually with black-box tests. Most QA groups work independently from the software team. However, in Agile, QA works closely with the team on an ongoing and daily basis.
Not focusing on testing early enough can cause significant problems, delays and rework. Correcting functional flaws can be time-consuming. But correcting performance or scalability deficiencies can require significant changes and modifications to the system’s architecture. If important system qualities are considered and addressed during earlier sprints, significant architectural verification could be performed much earlier, preventing significant disruptions or delays as architectural flaws are corrected. Agile teams incrementally deliver working software. Incremental delivery provides an opportunity to engage in QA activities much earlier, ensuring that in addition to functionality, important system qualities can be addressed in a timely fashion, rather than at the end of development.
QA in agile groups can benefit by being more proactive, working to ensure quality at all levels of the development process. Consequently, they can and do work closely and coordinate between business, management and developers. To be effective, Agile QA teams require additional skills to those of a “more traditional” QA team. For example, they often need to know how to understand the code, know how to write their own automated suite cases, and be involved in all parts of the agile process.
An important principle in most agile practices is the “Whole Team” concept. It isn’t just testers who care about quality. Ideally, agile testing involves a cross-functional agile team, with special expertise contributed by testers [CG]. Agile developers write unit tests to exercise system functionality. But there is more to quality than unit testing. Therefore having QA be a part of the team from the start can help build quality into system and make attention to quality part of a more streamlined process. This will help the team to know what system qualities are important and how they fit into the process (when to do what for different qualities). Another benefit of including QA is that they can help the team understand and validate requirements. QA also can help the product owner understand what quality attributes should be considered and when. And QA can assist the product owner with the definition of done which often needs to incorporate many important system qualities in addition to system functionality.