This is a guest posting by Nishi Grover Garg.
The agile methodology focuses on building quality from the very beginning of the software lifecycle. That is why we aim to find and fix defects early on: A defect found and fixed in an earlier lifecycle phase is a multitude cheaper than the same defect at a later stage.
But how can we more easily make it possible to prevent defects from percolating deeper in the software development lifecycle by fixing them in their nascent stages? Let’s explore ways to foresee, analyze and thwart defects in an agile context.
Communicate
From the early stages of a software project, we must develop a culture of open and frequent communication. Be it project planning, test strategy decisions, requirement discussions, or scoping of user stories, we must constantly discuss and ask for opinions from all stakeholders and team members.
By doing that, we encourage feedback on each aspect of the software, and the possibility of misunderstanding things is lessened. It’s important to strive to get everyone on the same page.
Conduct Reviews
Both formal and informal reviews can act as major strengthening tools for the quality of work being done. The software requirements specification (SRS), design documents, architecture diagrams, and user stories should be given to a team of reviewers consisting of different roles within the team. This ensures that the document gets a look from many different sets of eyes and fulfills the needs from all their perspectives.
Let’s say you had a review for a user story document about a basic login functionality for your mobile app. Though the details looked complete in the mock-ups, when reviewed by the tester, she questioned the performance requirements and benchmark login time for the app.
This may be an implied need, but because the story was missing the specific load times, it could have been ignored at the time of development and not been found until non-functional performance tests, which are usually conducted after a couple of sprints — or maybe not even until user acceptance testing. Any deviation or lag in performance would have been found later, leading to reoptimization of the code and costly rework.
A simple question raised by the tester during the review leads to a discussion and finalization of the benchmark numbers for app performance, which can then be taken care of during development and test when it’s more convenient.
Walkthroughs are another way of performing reviews on test-related documents of importance. I use walkthroughs to get the test scenarios I write for user stories for each sprint reviewed by the entire team, including the developers, dev manager and product owner.
In this meeting, I gather everyone and take them through my test scenarios (mostly one-line descriptions of my test ideas) for each user story. If anyone has improvements or suggestions, they give their input then and there, which my fellow testers note for us. This 30-minute discussion makes a big difference in the way the team perceives the tests being performed, and it ensures we all agree on those tests.
This also gives testers more confidence because they now have the backing of the entire team, and if they missed anything in their understanding or planning, they get those ideas before it’s too late. The chance of missing defects is reduced manifold.
I also have a firm belief in informal reviews. Having the team be comfortable in asking for each others’ opinions on their work, getting a second set of eyes to go through their creation, and being open to getting and incorporating feedback are the best ways to ensure things are done right in the first go.
This does mean that developers must get used to getting their code reviewed by their peers before checking it in. Many small mistakes in logic or understanding can get caught during such reviews and during the process of explaining the work to their reviewer. And because these informal reviews are not really documented processes, the author can be open to feedback without feeling anxious or targeted.
Demonstrate Often
As agile teams, we are supposed to deliver working software every iteration. This means the product at the end of each sprint needs to be working in all aspects, which we are supposed to demonstrate to our stakeholders. During these demonstrations, we get feedback about the features we built, and improvements may be suggested.
We must also try to do such demonstrations internally within the team beforehand. During development, we often get caught up within our own feature, but performing the end-to-end flow of the demo may help us zoom out and see how the feature we are building is working with other features. This is a great way to find integration defects sooner, and it takes the pressure off the final demo day when we’ve already viewed and reviewed our work together.
Perform Static Analysis and Continuous Integration
Code written during an agile sprint needs to be production-level every day. We should ensure that we are not putting off the finishing touches, insufficiently commenting, or slacking on following naming conventions and coding standards. Small design and understanding mistakes may lead to defects of high magnitude later on.
Adding checks using static analysis tools lets us verify the code as well as the potency of our unit-level tests. We can add these checks as part of our CI system so that we continuously get updates on the health of the code, and if it goes below a certain level, we can stop the build. This is a way to impose self-discipline so that we do not let the quality of our work drop at any point. Each step toward quality means fewer defects and less rework later on.
Prevention is the best cure for all bugs — even the ones in software! Defects that are prevented early on mean money and time saved. Consequently, we should take all possible prevention measures so that we have fewer bugs to deal with, fix and retest. I hope these tips help you on your agile journey. Looking for more Agile content? Read more on our TestRail blog here for updated posts on all things agile.
