Tightening the Software Development Feedback Loop

Agile software teams strive to stay flexible so they can respond to changing requirements during the software development cycle. Shortening the time it takes to find out if code works gives developers important information about whether to proceed in a given direction.

The agile manifesto for software development calls for “responding to change over following a plan.” Software teams bring this fundamental principle to life by developing products so that users and other stakeholders can try out and give feedback on iterative versions. Rather than following a detailed spec document written at the beginning of the project, each additional feature or function is conceived and developed in short sprints. This makes it possible for companies to build the software customers need today. Not the software they thought they needed six months or one year ago.

Who doesn’t want more feedback? However, for product managers and engineering leads tasked with getting software over the finish line, good feedback is a question of type and timing. Feedback at the wrong point in the development process can derail a project, but no feedback is also a recipe for producing the wrong software for a non-existent customer.

test IO exists because we believe that on-demand testing by real humans provides invaluable feedback that software development teams need to build better software. As we work closely with our customers, we learn more about when and how professional and reliable software testers can provide the most beneficial feedback in the software development cycle.

That’s why we’ve created, bug fix confirmation.

Software is never bug-free, but wouldn’t you rather know about bugs and prioritize which ones you are going to fix? Once you’ve chosen which problems to tackle and allocated time and energy (and sprint points) to patching an issue, getting the right feedback about whether the problem has been resolved is crucial to getting that bug fix released into the world. Especially in the case of verifying whether a bug has been fixed, having a tester who has a similar device, and is checking in the real world helps confirm that the bug is gone.

Testing isn’t always just about bugs. It is also about seeing how potential users interact with the software. Do they use it the way that you’ve imagined? Are the features they asked for the ones they actually use? (Reported preference vs. revealed preference)

In the particular development process for fixing bugs, timing and speed of feedback is important in a different way: then, it’s about making sure the fix works while the developer is still thinking about the problem. When a developer sets aside time to fix a bug that’s been reported, she’s delved right into the parts of the code related to the reported issue. Finding out that the fix doesn’t work on a particular device or browser, or creates a separate problem, is most helpful while she remembers the context and changes just made.

Being able to hear back from a trained tester in an hour or two that your bug fix doesn’t work is annoying, but hearing back from a tester or customer three weeks later that your bug fix doesn’t work is far, far worse.

If you'd like to see how crowdtesting can help you tighten the software feedback loop, reach out here.