Test Techniques to Manage Risk in Agile
A version of this article appears on Purple, Rock, Scissors.
Risk. It’s everywhere! There’s risk when we walk, there’s risk when we drive, there’s even risk brushing your teeth.
Some of you may not consider those examples as being the “riskiest” of situations, and that’s because we have everyday solutions in place to help us prevent the possible risks related with each of those activities. Going for a walk? Put shoes on to prevent hurting your feet! Going for a drive? Make sure you have enough gasoline in your tank to prevent getting stranded! You get it.
If you’re part of an agile development team, I don’t have to convince you that there’s constant risk involved throughout the life of a project that may prevent you from reaching your goal of delivering a quality product on time. To increase our chances of success, we have to become better anticipating instead of just reacting. Let me explain…
Anticipating vs. Reacting
Recently, my nephew challenged me to play a new race car video game. Despite the countless butt whoopings he’s handed to me in previous games, I respond, “let’s go, bring it,” truly believing that that time it’d be different and I was capable of winning.
The game begins, I smash all of the buttons on the controller until my car accelerates to full speed, I’m doing “really well,” when all of a sudden the completely straight road turns into a sharp right turn. My vehicle tumbles down a cliff and explodes into flames, followed by a sarcastic comment programmed into the video game to add insult to injury. All of this takes place in less than 10 seconds, and just like that, I’m done.
His turn. He effortlessly maneuvers his vehicle through the twists and turns while simultaneously avoiding a slew of obstacles each more challenging than the last completing the level in first place pretty much without a scratch.
We played the exact same level with the same car at the same difficulty — what gives? Is he some kind of boy genius (of course he is!) or am I just super terrible at video games? (Yep, that too.) Obviously, he’s played the game before and I have not. He was able to anticipate risk and finish unharmed, while I, on the the other hand, was reacting to it as it happened. And I lost.
Much is the same when working on our projects. Below are some things that anyone on your team can anticipate and why it’s a risk if you’re just reacting to them.
TEAM COMMUNICATION & COLLABORATION
You may be capable of being individually successful at your craft, but are you equally as successful when working with others on a team? To be considered successful on an agile team, a key ingredient is to be self-motivated and fully participate and collaborate with your team members to make sure you’re all on the same page. The very moment your team is no longer in sync, your team is in critical danger of not meeting your intended goal. Activities such as sprint planning and daily stand-ups completely lose their value if even one team member has not fully committed to the team and the process. We might as well hop up and down on one leg and start making our favorite animal sounds.
It doesn’t matter what title or responsibility you hold on a team, if you anticipate that just one of your team members is not fully committed or is overwhelmed by the project itself, it becomes your responsibility to help cultivate an environment where all team members feel comfortable and secure in sharing their contributions and having their questions answered. Any less of an effort and you’re putting the project and your own success at risk.
INCOMPLETE STORIES
A story encapsulates a feature from the perspective of a user’s role, describing what must be done in order for that feature/story to be considered done or “brought to life.” Because a story’s requirements may change often, especially during the beginning of a project, it may go overlooked, resulting in large or incomplete stories in our backlog.
Why is this risky? For one, it can lead to potentially delivering incomplete or unacceptable features to the client. Also, valuable time can be lost during an active sprint when you make assumptions on features and try to figure things out. Not to mention, incomplete stories are often an indication that team comprehension is not in sync.
In anticipation of this situation, review backlog items before the start of a sprint and examine each story. If you’re unable to clearly answer for whom the story is written, what is the feature, and why do we need it, you most likely have an incomplete story on your hands.
WRITING MANUAL TESTS
This is for all the testers out there. You know that for each story there may be a multitude of test cases associated with it. And you also know how often requirements can change in agile environments. When you’re constantly reacting each time requirements are updated, your workload increases exponentially with having to adjust test scenarios and manually execute the tests.
I’m a big fan of working hard, but I’m a huge fan of working smart. Let’s be more efficient shall we? Instead, design your tests to automate all acceptance scenarios. Then run exploratory test cycles to cover blind spots that your automated tests may miss. This drastically cuts down on the maintenance required to keep your test suites up to date, saving you both time and sanity.
Alright, wrap it up, Pedro
Process quality and the success of your project should not just be any one person’s responsibility; let it be engrained in your team’s foundation and culture. If you anticipate risk, be the one who initiates and encourages communication amongst your team members, no matter what your role. It’s easier said than done, but taking charge in uncertain situations is one risk worth taking.
Comment below if you’ve had recent related experiences or questions!
