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?
@Thong,
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.
Agree and looks agile, anh 🙂
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 🙂
@Tri,
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.
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).