Quality Ownership — Does it only fall under the QAs?
A product’s look and feel, as well as the correct functionality to achieve its purpose, can either make it or break it. However, should the responsibility of its quality exclusively fall under the responsibility of the QA team?
Quest for Quality
The quest for software quality is a never-ending battle. Testers around the world are continually struggling to let fewer bugs reach production, as well as obliging Developers to conduct initial tests for further prevention. When adding improvements and new features to a system, the implications are that the additional efforts related to the overall quality increase.
Testers! Do your job!
There is a concerning thought in development teams that Testers own, and are responsible for, all aspects of software quality. It’s true that they are continuously focusing on preserving the quality of a software product. However, we must remember that the output achieved by an agile team is the result of complete collaboration across the board. The effort towards completing sprint tasks is usually pursued by three primary roles: Product Owners, Developers and Testers.
The Product Owners
In a development environment, different areas of quality need to be taken into consideration, and that means various stakeholders must add their efforts to the overall quality. Firstly, the product has its defined business rules. If the Product Owner does not make these instructions as clearly defined as possible, how can the assigned tester verify that the system is working as expected? Consequently, the Product Owner must add quality to the overall process of development by making sure that whatever the business requires is thoroughly communicated.
Product Owners are also responsible for signing-off the work delivered by development teams, while giving an additional go-ahead after QA verification. According to the official Scrum Guide,
[the Product Owner is accountable for] optimizing the value of the work the Development Team performs
This, in the end, affects the product’s extrinsic quality (you can discover more about the details on extrinsic and intrinsic quality from Jim Highsmith’s Agile Project Management: Creating Innovative Products).
You can read more about how Product Owners within Catena Media add their value to our products on our Product Blog.
The Developers
Systems are constantly changing with enhancements and additional functionalities introduced by Developers. For this, unit tests are expected to be created and maintained to allow continuous validation of the system’s underlying logic. It is sensibly unrealistic if testers would have the responsibility of checking these unit tests as well, especially with the typical imbalanced ratio between Developers and testers within agile teams. Code coverage indicates that Developers are adding verification checks with each new logic within the system, but that does not eliminate the possibility that Testers may find issues down the pipeline. Developers should, for their benefit, help Testers with their quality efforts in any way necessary.
The Testers
It’s clear that Testers need to keep quality in mind at all times. With each area of the system that the team modifies, various factors need to be considered: functionality, security, accessibility, performance, device compatibility and much more. Unfortunately, it is very rare for Testers to be able to cover all, or even a few, of these quality factors. Instead, much of the sprint time is spent verifying and validating the functionality. That is the main reason why testers make use of test automation — to gain time and to be able to cover more of these quality factors.
Definition of Done
A method to make sure that the whole team owns quality is to define clear acceptance goals within the definition of done. Evolving Agile teams should periodically re-visit their Definition of Done to be sure that all checks still add value and quality, while also changing or refining it towards a less or more rigorous checklist. Test automation should be part of this checklist, as well. The team should spend some time within grooming sessions to discuss which scenarios are possible and feasible to automate so that Testers do not need to repeatedly verify previous test scenarios. The team must also make sure that with each new development, system performance does not deteriorate. This way, the whole team is aware of the testing efforts that can/need to be completed for their commitments to be planned better. If, and when, the tester asks for help on the automation part of the testing, both dev/QA efforts would be focusing and aiming for the same goal of completing the commitment. Software Testers should not be shy about asking for help. If you have obstacles within your automation, make it a team problem.
Way Forward
Promote collaboration. Testers should share their efforts and achievements. As mentioned, Developers should be involved in test automation, as they must surely find it exciting and contribute with their ideas! In the end, quality should be a team effort. Success or failure should always be in the name of the whole team.
Affected by all this quality talk? Have a look at Catena Media’s Product Team and UX Design articles, for more quality stuff!
http://product.catenamedia.com
http://design.catenamedia.com
For more interesting reads about Software Quality and Test Automation, have a look at TestAutonation.com.
