Bug: raise them fast or raise them with full information?


Please briefly explain why you feel this question should be reported .

Report Cancel

A bug with full information is always good. However, in many projects I had chances to work with dev team as internal and external tester. I have two kind of dev:

1. They like quick bug and no need full description, sometimes just image is enough. They love to fix it quick (sometimes no need to raise, just let them know what happens). Reading too many steps in bugs makes them sick

2. Whatever

We all know that writing full description bugs with complex template takes us ton of time. Not good for quick run projects but good for tracking propose.

So which team should fix themselves for better process quality? What we should tell our boss to improve the team?

solved 1
General 6 Answer 3167 views 1

Answers ( 6 )

  1. Thanh Huynh
    May 21, 2015 at 9:34 pm

    Please briefly explain why you feel this answer should be reported .

    Report Cancel

    I share your concern which is not uncommon in testing. So, my answer is it depends :-) :

    *If testers and developers are co-located (means they are in the same room) and they both work closely together, quick bug raising is acceptable. It's clearly there's no reason to spend 30 minutes of filing a bug while 5 minutes talks works the same

    *However, if testers and developers are not co-located (offshoring), a detailed and well-written bug description will help things run smoothly. This also helps avoid mis-communication for those who are using English as second language.

    There's no one-size-fit-all rule in this case. Let's consider which way makes team comfortable to work with.
    Best answer
  2. Thong Khuat
    May 25, 2015 at 5:36 pm

    Please briefly explain why you feel this answer should be reported .

    Report Cancel
    Agree and looks agile, anh :)
  3. quangtringuyen
    June 10, 2015 at 9:21 am

    Please briefly explain why you feel this answer should be reported .

    Report Cancel
    I think raising a bug quickly and full information is depend on some of many factors. But when raising a bug, it will show for other people (programmer, tester, BA, PM) your careful. I will take 2 cases:

    1. Raise quickly bug: less information, image only needed. So what happen if you open bug and other person test it or another programmer trying to fix it???
    Of course, they cannot reproduce the bug, dont know how to test it, am i correct? Except if they are expert on it.
    And then, if issue after fix still escape on production, what happen, they will not have full information to look back in the pass as they cant remember.

    2. Raise a bug with full information: Everybody, developers who working on that project are able to fix it, test it because they can read information of that bug and understanding what need to be done without the owner of bug (in case that owner went to holiday, vacation).

    With me, i used to open a bug with full information like Pre condition, Steps to reproduce, Expected result, Actual result, Comment... It doesnt take much time but it show how careful we are.

    Just my ideas :)
  4. Thanh Huynh
    June 11, 2015 at 9:14 am

    Please briefly explain why you feel this answer should be reported .

    Report Cancel

    You're right. We need to balance between quick bug and bug with full information. Either one, we need to understand what we are trying to achieve with bug reporting.
    June 29, 2015 at 12:42 pm

    Please briefly explain why you feel this answer should be reported .

    Report Cancel
    As long as I can fulfilled the following info, I public my bug: to teammates, local devs. Sure more details will be added later but publish first.

    1. Issue: what's going wrong? What is the bug to our user?
    2. Key steps: Which screen? What is the trigger?
    3. Expected result: How it should be? Your suggestion?

    Sometimes with a single screenshot you have them all.
    Sometimes with the Summary field only you have them all: "On Scheduler page, should NOT display timepickers when allowing enter Date only"
    Sometimes it requires example input, similar issue, .... but those key info should be met I think. Let me know your comment(s).

Leave an answer

Thong Khuat R

About [Thong Khuat]

Thong has 5 years experience in offshore Test Engineer position with 3 years in charge of Manual Acceptance Testing, 2 years in charge of Automation Acceptance Testing. Thong has passion on learning and practicing in-depth test methodologies specialized in test strategies, test design and requirements analyzing.