Quality? I own it? You own it? We own it!
Quest for Quality
The pursuit of quality is a never-ending battle. Testers around the world are continually fighting to let fewer bugs into production. They are also demanding better state of code within tickets before developers rush them for testing. When teams add improvements and new features to a system, it also implies that the required effort related to the overall quality is increasing. This matter appends to the complexity also mentioned in our previous post about the test pyramid, that the agile environment already imposes time pressures in reaching sprint goals. The representation of quality is found in various features of the product. It is not just within the correct functionality of the product that the user perceives quality. There is also the non-functional aspects such as performance, security, accessibility and browser/device compatibility. These also contribute or negatively impact the overall quality of software.
“Tester! Do your job!”
There is a concerning thought in development teams that testers solely own quality. Developers from time to time, tend to trust their faith blindly on their coding skills as well as the skills of testers by skipping their quick checks. It is a fact that testers are continuously trained and focused on preserving the quality of a product, however, remember that the output is the result of full team collaboration. The effort towards completing sprint tasks is usually the pursuit of 3 primary roles:
The Product Owner
With the multitude of quality factors within a software product, the various stakeholders of these areas must add their effort to the overall quality. First off, the product has its defined business rules. If the product owner does not explicitly describe requirements, how can testers confirm the expected outcomes? Therefore the product owner must add quality to the overall process of development by making sure that what the business wants is thoroughly communicated. Product owners are also in charge of signing off tickets, giving the final go-ahead after the one from testers. According to the official Scrum Guide, the Product Owner is accountable for: “Optimizing the value of the work the Development Team performs.” which in the end affects the product’s extrinsic quality (You can discover the details on extrinsic and intrinsic quality from Jim Highsmith’s Agile Project Management: Creating Innovative Products.
The Developers
Systems are continually changing with enhancements and additional functionalities introduced by the developers. For this, the developers must create and maintain unit tests to continuously validate the underlying logic of the system. It is sensibly unrealistic if testers would have the responsibility of checking these unit tests as well, especially with the typical imbalanced ratio between devs and testers within agile teams. Furthermore, code coverage indicates that the developers added quality gates with each new logic within the system, but that would not necessarily mean that all permutations and possible bugs have now been avoided. Therefore, developers should also for their benefit, help testers with their efforts and safeguard quality in any way necessary.
The Testers
It is clear that quality has to be continually on the mind of the tester. With each area of the system that the team modifies, various testing factors should be in consideration: functionality, security, accessibility, performance, device compatibility and much more. Unfortunately, it is rare for testers to cover all or even few of these factors. Much of the sprint time goes towards testing functionality. Testers make use of test automation to gain time and be able to cover more of these factors. Since quality is the primary focus and the persistent concern for this role, the drive for a better product is the main quest for each tester.
Definition of Done
A way to make sure that everyone owns quality within a team is to define clear testing goals within the definition of done. Evolving Agile teams will see a shift in their definition of done towards more rigorous checklists. Therefore, test automation should be part of this checklist. The team should spend time within grooming sessions to discuss which scenarios are possible and feasible to automate. The automation of these test cases would then allow testers not to cover previously tested scenarios repetitively. Also, it would be worth introducing a set of acceptance criteria related to non-functional requirements such as performance. Hence the team must be sure that with each new development, the system performance does not deteriorate. A collection of security and performance checks should be followed to control the impact caused by code changes.
Therefore, the whole team needs awareness of the testing efforts to be completed and thus plan their sprint commitments accordingly. When testers ask for help on the automation part of testing, this dev/QA effort would be going for the same goal of achieving the commitment. Testers, do not be shy about asking for help. If you have obstacles with your automation, make it a team problem.
What else?
Promote collaboration and consequently share your efforts and achievements. Involve developers with test automation, they will gain interest and will contribute to different ideas and perspectives! In the end, quality should be a team effort. Success or failure should always be in the name of the whole team. In conclusion, ensure that everyone owns quality as this is clearly another successful way of promoting it within the process.
References: Dan Tousignant, Who Owns Quality In Agile?
Originally published at https://testautonation.com in 02/2018.
