How can you reduce risk when implementing agile development in your SDLC?
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 (both from a technical and a business perspective) gives developers important information about whether to proceed in a given direction.
Part of the agile manifesto for software development calls for “responding to change over following a plan.” Many software teams bring this key principle to life in 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 within a short time frame. This makes it possible for companies to build the software customers need today, not the software we thought they needed 6 months or 1 year ago.
Who doesn’t want more feedback? For product managers and engineering leads tasked with getting software over the finish line, getting and managing feedback is a question of type and timing. Feedback at the wrong point in the development process can derail a project, but no feedback at all 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 the 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 a new product, 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 make sure that bug is really gone.
Testing isn’t always just about bugs, it’s 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 certain 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 3 weeks later that your bug fix doesn’t work is far, far worse.