Software bugs are inevitable, but quality improves when you find defects sooner rather than later. Adopt these measures to cut down lengthy and expensive software feedback loops.
By
- Matt Heusser,Excelon Development
Published: 31 Jan 2019
The later testers find software defects, the more expensive they are to correct. This economic reality holds especially true for Agile teams. In fact, the quality of an IT organization's Agile feedback loops determines how much the enterprise gets out of the methodology. So, you want to find bugs as soon as possible.
Software feedback loops help people find, report and fix bugs. Feedback can occur between testers and programmers, and from end users to the software team. The more software makers tighten feedback loops, the better they can address defects and boost productivity.
It's hard to resolve defects found late in software projects in a quick and simple fashion. QA estimates the scope, tracks the bug and, eventually, assignsitto a programmer. However, that programmer must first finish other work before he starts to fix the bug, and he might not even be familiar with that aspect of the application's code base, causing further delay.
Compare that workflow to one where a QA tester makes a programmer aware of a defect the same day it was added to the source code. The programmer can fix the bug quickly with the context for it still fresh in his mind. That's why fast Agile feedback loops make a difference.
Here's are six ways that Agile teams can tighten their feedback loops.
1. Put testers and programmers in the same room
Reduce the distance between testers and programmers. Testers can't easily notify programmers about defects when the organization siloes each group from the other, and it's harder for programmers to fix bugs the longer ago they created the defects.
Place testers on an assembly line of sorts, where they take the work from the programmer and immediately inspect it. If the tester has a question, she can turn to the programmer and ask him directly. The goal is to detect the bug before the programmer moves on to the next feature.
One of Agile's most transformative changes to how software gets built was to take testers from a separate group with a separate manager and embed them into specific development teams. Simultaneously, testing also shifted to focus onone feature at a time, instead of end-of-line system testing.
Some teams even embed testers the programming process, meaning they flip between code and test frequently, and even contribute to code.
2. Reduce work in progress -- and reduce it again
Measure average work in progress (WIP) and cut it by 10% to 25% -- then, cut it one more time. The software feedback loop will get shorter, and you can fix the application more quickly.
Envision an overworked team: Programmers work on 10 things at a time, support multiple projects, hit roadblocks when they can't get answers to their questions and hit more snags when a pull request gets blocked. Nothing in that WIP-heavy way of working is conducive tofast software releases.
Now, picture a team where programmers work on one thing at a time. When the tester evaluates a programmer's work, the dev waits until they finish looking for defects. This second team has little to no task-switching costs or delays; in my experience, each individual task can get done as much as 30 times faster than in the hands of the overloaded team.
3.Shorten testing preparation time
If you spend a long time preparing tests, you could delay the development process -- which makes the test feedback loop longer.
Some groups spend a lot of time preparing tests. They create test strategy documents, master test plans, test cases andother documentation. Finally, when the test documents pass review, actual testing begins.
A capable tester should look at the work that's done and create a test plan concurrent with the actual testing. Some argue that many testers are simply not capable of this approach -- that a QA lead must tell them what to do. But, if testers have the aptitude to multitask, train them; if they don't, maybe they don't have the aptitude to do effective testing.
Know your loops
An Agile team can have one to four software feedback loops at any given time:
- a developer testing her own work;
- a second person testing a feature;
- the final shakedown test before a release to production; and
- customer feedback.
Additionally, some teams might have periodic automated tests, a CI run, performance testing and other types of checks that cause delays. When debating which loop to tighten, evaluate how valuable shorter time to test results is, and how easily you can improve the loop.
Write down the process, and if you'd like, study estimated times for these loops in a sprint. Figure out how to slice off a piece. For example, you can skip tests that never yield useful results. In some cases, these tests are redundant. Also, an investment in shorter loops, such as automating the setup process, could have other benefits, like automating the build process as well.
Sketch it out, give it a try, look at the results and repeat.
4. Set up test environments quickly
A lengthy test environment setup slows down testing and delays feedback, so identity and address bottlenecks in that process.
If it takes hours to set up a test environment, testers will likely do that work once per sprint, which further separates development from testing. If setup takes days, your Agile team might inadvertently be stuck in what is effectively a Waterfall model.
Figure out what takes so long in the setup. Once you identify the bottleneck, reduce the delay. For example, if data creation is an issue, build a batch program to load data into a database. If server availability is a problem, move to an automated, push-button processto create a standard serverfor any given build or branch.
5.Improve first-time quality
Reduce the number of defects you introduce in the first iteration of software. The more bugs you create, the more trips through the software feedback loop happen. Many software defects happen because of a lack of attention to detail or misinterpretation of vague directions. When such bugs become too common, programmers can't advance to create new features.
To fix this bottleneck, reduce the defect injection rate: the total number of known defects per iteration. Analyze theroot causeof these missteps, and remove them to improve first-time quality. This shift in approach often draws testers into the creation of software requirements.
6.Balance automated and manual testing
Naive attempts to add automated tests on top of a legacy system will probably add cost, time and not much benefit; so manual testing should persist.
Obviously, test automation can accelerate the completion of a test feedback loop, but teams easily overemphasize it. Human testers examine the software in a way thatautomated tests can't.
Unit tests and test-driven development, along with amodest amountof automation, can improve first-time quality. For example, a light build verification test can help; just don't overdo it.
Next Steps
10 tips for effective change management in Agile
Embrace these Agile sprint planning tenets
Dig Deeper on Software testing tools and techniques
- Choose a software testing model by weighing these 5 factorsBy: MattHeusser
- Learn what to test in a mobile applicationBy: MattHeusser
- The Three Ways (The Phoenix Project)By: WesleyChai
- User acceptance testing best practices for Agile teamsBy: GerieOwen
