What do you do when you find a bug?

What do you do when you find a bug?

Hold on do not answer it right now. Let me first set the context.

You are part of an agile team. The developers sit opposite to you. You are testing a feature in a session. You are time bound and have the good habit of capturing notes when you test. When you now find a bug what do you do? Assuming that you have taken enough notes you go on to write a good bug description and may capture a screen shot, video of the bug and continue with your session. At the end of the session do you

Open the defect tracking tool (wait for it to load), enter all the fields for a bug, upload necessary evidence and have the tool share the defects with your dev team?

Or

Open the defect tracking tool (wait for it to load), enter all fields for a bug, upload necessary evidence and then compose an email to the dev team with the bug id’s/descriptions?

Or

Walk to the developer share your notes; reproduce it if required, work together to identify the problem?

I work in an agile team; we collaborate together with the dev team to deliver our stories and in turn the product. When we find a bug we walk up to the developer, share our test notes and bugs with them. If the developer have more questions we work together for may be 30 min to try identify the root cause together. We then attach the session sheet to the task in mingle (project tracking tool) and update our coverage sheet. If we identify a bug as “out of sprint” we log it in mingle.

I have seen that this process is much quicker. It takes approx 1 min to ask if the developer is free for an update and the next 10 min to update the session notes and bugs.

Apart from a quick feedback, this process has also helped in bridging good communication between testers and dev team. Dev team are amazed by the scenarios, test notes captured during testing and this has lead to admiration of the test team. Testers understand and learn more about the system every time they pair up with the dev team to discuss test notes.

This process has made me wonder if it’s time we need newer, lighter, interactive defect tracking tools? Or do we need it all? I might write a series about this.

But, for now it would really help me if you answer -> what do you do when you find a bug?

Comments

Anonymous said…
I did as you do, walk up to the developer when I found a bug.

But after several times being complain by developer, I stop doing this.
They (devs) said: "Don't bother, I'm working on a major function now, leave your bug on Defect Tracking tool then I will take a look on it later".

So now, when I find a bug, I report is using a defect tracking tool then reminder devs that there are some new bugs for them now.
July 29, 2011 at 7:57 AM
Tester said…
I work in a project where there are 13 developers when ever we go and interact with the dev about an issue. They tell us that they have some important work to do. but when ever we post some thing in Issue Tracker with a milestone. Then they will look into it and try to interact with us.
July 29, 2011 at 9:32 PM
Sharath Byregowda said…
@Anonymous @Tester - It all depends upon the project context. Don't be annoyed when a developer says "he is busy" they have their tasks and they might be in the pressure to develop and release it. To me communicating with the development team is a key skill a tester has to develop. You need to find the right time and tone to talk to them. Also I am not sure of the process you have in your team. Talk to your test manager, dev manager if you feel there is more value in sharing a bug when u find it. But please keep in mind that you need to evaluate what fits your project context and team.
August 1, 2011 at 3:32 AM
Anonymous said…
The first thing I do is repeat the test to verify it actually is a bug, and not just a vagary of setup or environmental factors! Once confirmed, I'll approach the Devs and ask how they'd like it handled - immediate quick investigation or log and leave. It's their choice, based upon their workloads unless it's a showstopper for further testing.
August 1, 2011 at 2:29 PM
Darren McMillan said…
Nice post Sharath,

Myself, I more often than not walk over and chat with the developer about it.

Sometimes though the bug is so trivial or apparent that there is no need to chat with the developer about it, so I'll just raise a bug report, or fix it myself.

For me, when I get up off my seat to chat about a bug it's to clarify the issue for both parties, which most often than not results in it being fixed quicker.
August 1, 2011 at 7:59 PM
sarmila said…
I walk to the developer to let them know about the bug and to discuss further.

As mentioned in one of the previous post initially I heard "please add to the bug tracking tool". After some time I started to ask "Have you got sometime to look into the issue that I have or should I post to the bug tracking tool?". Most of the times the answer was letz look into it now.

Also I noticed sometimes the bug fixes did not get to the release build. Since it was not logged in the bug tracking tool it was hard to trace them.
August 2, 2011 at 12:12 PM
Sharath Byregowda said…
@Anonymous very good point -> “repeat the test to verify it actually is a bug, and not just a vagary of setup or environmental factors”
August 4, 2011 at 10:15 PM
Sharath Byregowda said…
@Darren I am a bit confused when you say “fix it myself”. What do you do after you fix a bug? Does fixing even a trivial bug not take your testing time? Will you be expected to fix some bugs after a while?
August 4, 2011 at 10:15 PM
Sharath Byregowda said…
@Sarmila It’s nice to hear that your dev team want to work on an issue together. But, if the bug fixes do not go to release build its basic discipline that’s missing in the process.

How will it help if you log the bug in a bug tracking tool? How will you trace them and ensure the fix is checked into release build?
August 4, 2011 at 10:15 PM
Software Quality Nut said…
We still post the defect. Seems you write 'waiting for the bug tracking system to load' quite a bit. I'm wondering what system you use that would seem to take so much time to load. I think its still a good idea to log the defect for tracking purposes. Otherwise you get no information other than gut feel if things are getting better. As far as all the details go, maybe just walking over to the developer is more efficient rather than doing screenshots, specific reproduction steps (maybe still put in the defect report but not so detailed), etc.
We do a lot of agile work as well, but still feel its worthwhile to officially post the defect.
April 29, 2012 at 7:11 PM
Sharath Byregowda said…
Thanks for the comment Software Quality Nut

We used HP QC. I have used other bug tracking systems before like JIRA, Mantiss, In house, Bugzila, etc. Be it any tool they all have their own constraints.

To me its the context which should define the process. Our project context demanded rapid feedback and we were able to achieve it. We still had our bug descriptions in session sheets for evidence sake :/

But I do not understand this. How do you get information that "things are getting better" with bug reports?
May 2, 2012 at 1:00 PM
Unknown said…
The Bug Tracker provides a totally open forum for creating, discussing and fixing bugs in . The Bug Tracker adds is the direct, one-to-one collaboration with other developers fixing the bugs most important to you.
Bug defect tracking
August 6, 2013 at 1:24 PM
Post a Comment

Popular posts from this blog

Exploratory testing, Session based testing, Scripted testing…concertedly

In my last assignment a mix of exploratory, session based and scripted testing helped won an award, appreciation by managers & stake holders at our organization. The quotes from our award certificate “ QA team has come up with some intelligent testing techniques to validate the product. The customer test team was not able to find even a single critical bug after delivery ” Though the award was a small one in terms of the award categories our organization have, it meant a lot to me and the team, because this was the first time the team used exploratory approach. The assignment was not pure exploratory or session based, in fact it was supposed to be scripted, but a mix of all three exploratory, session based and scripted testing helped us learn, enjoy, and meet our mission. The assignment started off with developing test cases. We wrote test cases based on the initial requirement document provided. We did come up with a large number of test cases, of which most were re-written, some
Read more

Regression Checks + Regression testing = Regression testing?!

One of the questions I find hard to answer when I use exploratory test techniques in my project is,”How do you run regression tests? How do you prioritise them? Do you automate them? Do you document regression test cases?” And then a bunch of questions follow. Let me define the context. I work closely with developers; we use either Scrum or Kanban - which ever best suits our project, product owner, business. We do not believe in individual metrics, blame games, stringent processes, and heavy documentation. All we care about is to deliver high quality software. This does not mean that there is no process, metrics or documentation. We have them all, but they are there to meet our needs and to help those who will come onboard to support/maintain the software. Regression Checks At the start of a story, testers pair up with developers to develop feature files using SpecFlow. Some call it Acceptance Test Driven Development and others Behaviour Driven Development [I am yet to figure out the d
Read more