The Lost, Ancient Art Of Opening The Perfect Bug

If you’ve written code for LoadRunner, you may have been lucky enough to work with The Master. If you were calm and patient, you may have even been shown The Way. The great secret. The lost, ancient art of opening the perfect bug. A bug that no dev can close as “description not clear/does not reproduce/just won’t fix it”. One that is so easy to find and resolve that it makes devs look like hotshots. A bug that you, as a developer, would like to receive yourself so you could quickly fix it.

The problem: getting imperfect bugs sucks

The Master sits quietly at his desk, drinking his tea and smiling mysteriously at a joke only he seems to get. You approach him modestly, seeking help. You’ve opened bugs and assigned them to other developers, but for some obscure reason, they don’t like that. Same as you, they prefer to keep writing shiny new code and drink coffee, rather than try and debug something they’ve written in the past. A year or a week ago, it makes no difference – even two minutes ago is already too far gone for them to care. After all, devs are the Zen monks of the tech world: we only code in the now.

The Master: finding the root cause

You quietly share your pain with The Master. He is not angry with you. Few have seen him get angry and lived to tell the tale. Instead, he smiles and insists you, the esteemed guest, sit on the only chair in the cubicle. He then slowly gets down on his knees in front of his keyboard and starts investigating the bug you’ve been facing.

In what seems like an instant, he ends up finding the root cause and sends you happily on your way with the perfect bug description. If you had been watching him patiently after repeating this ceremony several times, you may have trained and leveled up your bug investigation and description skills. Borrowing from the late Sir Terry Pratchett, Mayherestinpeace, you have learned Deja Fu: the lost, ancient art of solving a bug by making it happen again and again and again.

The Way: levels of bug opening

The Master can lead the developer to the path, but the dev must be the one to walk it. Should you choose to accept this journey, the following are the levels of debugging enlightenment that lie ahead. Keep practicing, and in time you shall reap the rewards.

Novice: Say that something went wrong

We’ve all received and opened such bugs. And we’ve all closed them almost immediately. It’s even possible we’ve complained about them loudly or threw something at the person who opened the bug. “Something went wrong?” Is that really all you can tell me? How am I supposed to fix the bug? Tell me what went wrong, how to reproduce it, and how to verify my fix. Sounds basic, right? True. But you have to start somewhere.

The Master may call you a “grasshopper”, other developers will use ruder words, and you will keep on sweeping the floors until you level up.

Intermediate: Say WHAT went wrong

“I clicked a button and the app crashed.” “I called an API and it returned a 404.” “I was unable to install the app.” It’s easier for the developers getting the bug to understand what happened, and if they realize how important the problem is, they may not rush to close the bug as “won’t fix”. Instead, they will reach out to you and ask you for hints that may help reproduce the issue.

What were you doing? Which OS, browser, language, and device were you using? What state was the app in? What did you expect, and what actually happened?

Repeat this exercise enough times, keep filling up those buckets of water, and you will reach the next level.

Advanced: report what you were doing when something went wrong, and how to tell it’s fixed

“I was running the app on an iPhone 8, iOS11, English. At the time I invoked this function with these parameters, this was the state of the app. I expected it to return X. Instead, it entered an infinite loop, colored my iPhone pink and started playing “never gonna give you up” from the speakers.” Developers receiving this bug will know exactly how to reproduce it – just get the app to the same state, and call the same function with the same parameters. They will thank you and write some automated tests to verify the fix and make sure the same bug won’t happen again as a regression.

You have earned your place among fellow bug openers. Keep practicing this art until The Master finally lets you into the inner sanctum to read the scroll of the Dragon Bug Opener.

Master: provide a short, verified method for reproducing the bug and for validating its fix

For an API, provide a call that fails while there is a bug, and passes when it’s fixed. For a UI element or a usage flow, do the same with a UI level script (TestCafe, Selenium etc). Developers you’ve assigned such bugs to may hug you, and will in all probability bow down before your wisdom. For you have provided them with an (almost) perfect bug. One they can easily fix, one that will always reproduce and will never again appear as a regression.

You may now drink your tea with rancid yak butter, smile modestly, and get back to work. You may even pass on your wisdom to other novices. And you may keep spinning the prayer drums, for there is still an even bigger secret to discover.

Supreme Grandmaster: just point me to the broken line of code and tell me how to fix it

This level of mastery is so rare and dangerous, that only a few developers even believe it exists. This is the one true secret wish of every dev. Don’t ask me to dig through my code. Just show me where the problem is. I’ll fix it and then get back to drinking coffee or writing new features. This is the true secret. Open a bug as if you were opening a bug to yourself: with the solution neatly wrapped up.

If you have reached this level, there is nothing left for me to teach you. Except, possibly, point you at a shiny new tool that may help you do it faster.

Do try this at home

Reaching the Supreme Grandmaster level, or even the Master level is easier said than done. Traditionally, the people who test the code or find bugs in it are not the people who wrote the code. After all, had I known there was a bug in my code, I wouldn’t have shipped it, right? The people who find the bugs don’t always have access to the code. And if they do, they don’t always have the ability to run it in debug mode.

But what if I told you there is a tool that makes this possible? A tool that lets more people in your dev team set breakpoints in the code and track a bug to the very code line that causes it?

What if the next bug assigned to you would not only come with the perfect description, the method for reproducing it and for validating the fix but also had the exact line of code for you to start from? What if you clicked that bug description and were redirected to a web IDE with ‘non-breaking breakpoints’ set in it, allowing you to quickly reproduce the bug again, without stopping, even in production?

Sounds too good to be true, right? We thought so too. But it actually works. Take us up on it, and try Rookout with your testing team 🙂

Conclusion

Like many other art forms, the secret to opening a perfect bug involves a lot of patience and practice. But the key to it is simple: open bugs unto others as you would have them open bugs unto you. Open a bug you would like assigned to you: a clearly defined and easy-to-reproduce bug. Preferably with a quick link to the exact line of code you need to change.

The easiest way to fix bugs this way is Rookout – a rapid debugging tool that lets you debug live applications without breaks, restarts, or writing more code. With Rookout you can set ‘non-breaking breakpoints’ on an app running in production, dev, or staging, and track a problematic flow to its source.

And if you happen to see The Master, be kind to him. Share a humble smile, and remember his Way, strange though it may seem to you at first. And enjoy the tea.