This blog post was contributed by Tara Walton, Education Manager at Provar. Use the filter on this page to find more posts from our University of Provar team!
Testers often get a bad rap for finding and pointing out failures, but failure is the best teacher when it comes to learning. Unfortunately, failure comes with a heavy connotation of doom and gloom. We don’t usually consider that every refinement, improvement, or innovation has come from a long string of failures. Often, we’re learning or trying something new as we build out the next set of features.
It’s important to learn new things and test our innovations so that we can dust ourselves off when failure knocks us down.
Here are 3 ways you can recover from a bad outcome.
Put It to the Test
When a feature or component keeps failing, don’t get too disappointed. It just means you’ve discovered conditions that aren’t desired.
Remember, a test that can’t fail isn’t much of a test.
When something goes wrong, it’s the perfect time to script a new test because you know it will fail in its current state, and you know what conditions you want to avoid. Adding tests for those undesirable conditions means you can ensure your safeguards in the future.
Test Driven Design’s key methodology is starting with a test that fails. But that doesn’t have to apply only to software solutions. When a process or requirement fails, you — gather data, document, and put in some more fail-safes. You got this.
Hindsight is 20/20
Retrospectives help us determine if design, code, process, or expectations fell short of success.
Your QA team doesn’t just check for code quality.
They also check that requirements, business needs, and processes are working together as needed to ensure success. Taking the time to figure out which failure is happening and how to address it in the future keeps teams on the same page and moving forward.
There’s also the bonus of figuring out what went well even when the whole project feels like it might catch fire at any moment!
Docs or It Didn’t Happen
Make sure to document any decisions made and what caused the failure.
Living memory isn’t as reliable as most people want to believe and we can never guarantee our team will be the same in a year, month, or even a week.
Giving new or missing team members (not to mention your own brain) a reference point to refer to can save a lot of time and analysis should the issue pop up again. This is even helpful when one failure has been solved, but another springs up in its wake. So often, one bug is covering for a larger problem, and it is in the documentation and analysis that we can find that root cause.
There’s no use ignoring a problem or looking through rose-colored glasses. Embrace those failures that get you down as a learning experience that will only make you (and your product) better from here.
We have faith in you and are here to help every step of the way! The University of Provar and the Provar Forum offer more best practices and tips.
Want to learn more about the University of Provar and our many free courses and certifications so you can continue learning? Visit the UP page!