How BDD saved us from a pitfall

In November 2016, the Stutern team set out to ameliorate the Stutern application as mentioned indistinctly in this post, which if you haven’t read you should go check out now.

Like the pony in the apple store, we simply weren’t looking at a pitfall we have stepped a foot half way into. This pit right in front of us wasn’t an empty one. It had searing fire but we still didn’t see it.

We saw the flames, our users saw it too and those that were expressive reminded the team of the obvious. We had identified that we were about to get burned we just didn’t know how. We didn’t see the pit. As a team that values user feedback and puts in effort to achieve user-satisfaction, we knew we had to do something about this flame. We wouldn’t want to take down all our users with us if we get ablaze. Then we tried to pay more attention to the flames to find its origin.

We heard a distant voice scream BDD!! What was that? asked the team leader. I said I think I heard BDD. What the heck does that mean? Someone with a google-fu to the rescue. Oh that’s Behavior Driven Development. Okay so how does this help us find and kill the flames? We dug a little deeper into the internet of webs and decided to give this a try. It doesn’t look like it’d hurt right?

We started with user stories for acceptance testing. After gathering some post-it notes and markers, all that was left to set us on recovery was actually putting them to use across the team.

As a X I want Y so that Z

These user stories served as an acceptance criteria for features that would be built into the application at a broader scope. We have requests from our users, requests that align with our business needs and we needed to accommodate them all in the application.

This gave the team a healthy time to rethink every approach with the opinions of every team member weighed in along with user feedbacks. The earlier version of Stutern had followed the mantra: move fast and break things; and like you’d hope there was so much broken.

move fast and break things by xkcd (https://xkcd.com/1428)

Even the big guys have learned not to do this anymore.

We gradually moved our post-it notes to a Trello board which we follow till today. This list defines the tests that we write, which in turn defines the features we build.

Testing models and helpers with Rspec

These tests addressed the issues we were having. While some aren’t fixed till this moment at least now we know how to tackle our problems. We’ve seen the pit and we’ve learned to cross it. A lot of companies haven’t crossed it completely like us. We believe we can with your help. We need to cover the pit hole for a safe cross and we’ve only gone halfway with that. Show us the flames when you find them.

If you find bugs on the application or anything at all that can be improved, you can use the support chat widget at the bottom of the website or send an email to team@stutern.com. We need more feedback from you, our users, to help create a better experience.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.