On September 9, 1947 the first instance of an actual computer but was found.

At 3:45 p.m., Grace Murray Hopper records the first computer bug in her log book as she worked on the Harvard Mark II. The problem was traced to a moth stuck between a relay in the machine, which Hopper duly taped into the Mark II’s log book with the explanation: “First actual case of bug being found.”

That’s over 65 years ago. Since then all kinds of problems have been found in computer hardware. The term bug continued to be used. With time it’s also transferred over to computer software. Now we call almost any mistake in any process a bug. Thankfully, I’ve never literally found a bug in software that I’ve ever tested (though I’m still looking).

Today I want to talk about 6 things you should do after finding a bug (the normal kind).

1. Enjoy The Moment – I’ve seen testers get really upset when finding bugs. They’re mad because the system doesn’t work. It can be frustrating to encounter issues that block you. With deadlines looming, and other pressures put on teams finding bugs can be the last thing you want to deal with. Trust me it is easier when everything thing just works, but that’s not your job. Your job is to find bugs before customers do. Your job is to be both the hero and the villain.  When you find your next bug give thanks (even if it’s silently to yourself) because you’ve helped someone. You’ve helped the customer.
2. Try Reproducing The Issue – Trying to reproduce the issue helps you in a few ways. You get a clearer understanding of the steps to reproduce. You see if the bug is intermittent, and half the time you’ll think you’ve found a bug when you really haven’t.
3. Start Testing Other Related Scenarios – Bugs are always a part of a colony. When you find a bug in one area it’s pretty common to find other related issues. So after something is found keep searching you don’t know what else you’ll find.
4. Note The Current State Of The Application – This can also help you discover if the bug happened because of an external issue. Do don’t only want to the steps to reproduce the issue but also the current state of the environment where you are testing.
5. See If It’s Already Been Reported – Some bugs have already been reported and filed. There’s no point in doing work that’s already been done. If you can add any useful information to the ticket you should do that also.
6. Report It As Soon As Possible – So after discovering that the bug hasn’t been reported (See step above), you need to report the issue right away. Bugs like to be identified, they want to be known. Give them there five minutes of fame. It’s easier to write a bug report that doesn’t suck when the issue is fresh in your mind. You also want to reduce the time of the feedback loop (time between code creation to validation). This helps the team be more productive.