Comment:     by govind p 4/25/2006 Danny, U r cen percent right. i also faced the same problem which u explained in the topic. U r very good in expressing QA person's thoughts. Its a good topic for buddies and experienced QA's
	Comment:     by Surendra Oturkar 9/13/2005 Its Nice Article, But still i think bug classification makes bug soving more easier and makes the area to work on the bug specific, so I think this point should also be considered. Author's Response: 4/25/2006     Certainly there are fields in a bug tracking database that should be used to classify the bugs in various ways, including severity, priority, and functional area. I only gave a brief glimpse into a part of the bug tracking process.
	Comment:     by Rameez ali 5/26/2005 Dear Mr. Faught, It was nice to know that the Defect life cycle related concerns of testers all over the world are nearly the same. And you have indeed put them in a very clear way. You are right, the developers look at the application from a different angle than Testers. I think both Developers and Testers should work in the contrary department to better understand the concerns and constraints associated with that job. I would appreciate if you could comment on that. Author's Response: 5/26/2005     Hi, Rameez. I think you're asking about how the organizational structure affects the testers' ability to get bugs fixed. I prefer to work closely with the developers, if the developers and development managers have a good appreciation for quality. However, if the developers don't really understand what the testers are doing and why, and the development managers don't encourage sound development practices, you may need a more formal and independent organizational structure in order to get your point across when you find bugs that should be fixed.
	Comment:     by Imran Jah 4/20/2005 Hi Danny, your take on 'Bugs & Psychology' (if I may call it so) is excellent. Just one thought, it is said that anything that does not match requirements is a BUG. But as testers, we must also look at things from Customer's point of view, thus, also taking care of the unstated but desired requirements. However, its not easy to get the programmers to think in the same light. What can be done in such situations..?? Author's Response: 5/26/2005     Get a good book that covers bug reporting, such as "Lessons Learned in Software Testing." That'll give you a lot of tips on how to be a good bug advocate. Filing an effective bug based on an unstated requirement requires a lot of understanding of the context that you're working in.
	Comment:     by Jehanzeb Riaz 4/12/2005 Excellent Article Danny, this is the reality and you explain it very nicely. Cheers mate….
	Comment:     by Yuriy Shvets 4/6/2005 Danny, I am doing exactly the way you have described in your article. I do have some issues I would like to post and maybe if possible to get some comment back from you. Consulting Company that have never had QA before and trying to establish processes and build QA department. Based on the project I am working on I have created the flow of Build deployment and notified all people on the team that testing will only be performed on QA environment. Lately my Project Manager has decided to implement some new changes. She wants me know to do a "Smoke" test on Development Environment Before I can actually deploy build to QA and do...Read On Author's Response: 4/10/2005     Hi, Yuriy. I think we need to have more of a discussion than this forum will allow. Feel free to send me email and I'll see if I can give you some tips. Doing a smoke test is not a bad idea in general, though you can debate who should be doing it. It sounds like there are some snags in the process you need to get ironed out, but it's hard to tell at this point where they are.
	Comment:     by Bahadur G. Asher 4/6/2005 Hi Danny, it's a very good and minute observation that you have done. We also many a times face a similar issue of programmers returns the bug sheet with comments such as "bug not reproducable" or bug not found. I found 2 major reason for this kind of thing happening 1st reason could be the bug is not explained properly or not enough steps are listed to reach to that bug and the 2nd reason is that the bug list is too big and there are other major bugs that need to be looked in and they did not had enough time looking into this bug. I also agre with you that if you look carefully then you will find bugs in clusters most of the time...Read On Author's Response: 4/10/2005     Thanks for your comments, Bahadur. One thing that helps me to write reproducible bug reports is to try to reproduce the bug on different systems - the more they differ, the better. Often I will be surprised that I don't see the bug on the second system, so then I have some additional isolation to do. I'll end up writing a much more useful bug report that the developer is more likely to reproduce.
	Comment:     by John Delaney 4/6/2005 Yes a very good article. On the subject of not reproducable defects, the defect should include steps to reproduce along with a system environment description. Author's Response: 4/10/2005     Thank you, John. I'm always making subjective decisions about how much detail to include. It's easy to think the ideal is to provide vast amounts of information, but if the bug is easy to understand, it's actually easier to understand with a succinct description. When I do provide lots of additional information, like a long stack trace, I'll try to put it in a part of the bug report where it won't clutter the main point.
	Comment:     by Venkatesan Kalingamurthy 4/6/2005 It is a good article. You are bringing a very good point on the relationship between tester and developer. The very important point I like is "to consider the human elements of the development process". Anyway both are working for develping a good product only. If we keep this in mind, bug triage meeting will not be a battle field Another point I may want to add is, sometimes bug may be returned to tester by saying "NOT REPRODUCIBLE". As a tester we should not close it just like that. We should take it with the programmer by explaining steps and environment that we have tested. In these situation we should cool our...Read On Author's Response: 4/10/2005     Hi, Venkatesan. At a bug triage meeting, my aim is to make sure the decision-makers understand the consequences of the bug. As long as I know I've provided the relevant information, it's easier to accept the decisions about priorities. Also, sometimes new information you find later will help escalate the attention a bug gets, so have some patience.
	Comment:     by Gandhali Samant 4/5/2005 ggod article. I liked the consideration of human element of the development process. Also the handlling of bugs if they are 'Not bugs' as per developers. Author's Response: 4/10/2005     Thanks, Gandhali. I do so much better now that I start with the assumption that the developer intended to do a good job among a variety of pressures, only some of which I'm aware of. But I'm not so nice toward the software itself - my attack on the software is unrelenting. :-)
	Comment:     by Paul Tsuda 4/5/2005 Danny, I really like this article, and I think you hit the nail on the head when you talk about good customer advocacy while remaining sensitive to the psychology of the programmers. Keeping this balance, doing this difficult dance, deserves the exposure you are giving it. Metrics and methodology are just empty words without this daily execution by experienced professionals. Author's Response: 4/5/2005     I'll give credit to Gerald (Jerry) Weinberg for opening my eyes to the people side of things. Technology is easy, compared to learning how to work effectively with the other people on a project.
	Comment:     by Robert Rose-Coutre 4/5/2005 Regarding a bug that is partly fixed -- If you close the bug, then open a new one to address the residual buggy behavior, be sure your test manager or some who attends meetings is up to date on it. In daily bug-report-review meetings (hopefully with at least a programmer, dev. manager, test manager, and doc person), the attendees are usually flying through the bug-report items as fast as possible. They will probably recognize the bug title and remember fixing "something like that" and drop it or "bury it," etc. This is especially likely in larger organizations with many testers reporting dozens of bugs per day, per...Read On Author's Response: 4/5/2005     Very good point, Robert. It's important to mention in the bug report the existence of the other similar bugs (so they don't think you're blindly filing a duplicate, and say explicitly why this one is different. Despite my best efforts to distinguish similar bugs, I've had bugs rejected in the manner you describe. In some cases, it's debatable whether it's really one bug or two, and the path of least resistance is to make to sure to track all aspects of the problem within one bug report. Then you can be ready to file additional reports if a fix comes in that doesn't cover everything. Timing is important.
	Comment:     by sushant mishra 4/5/2005 Hey,Its a ood article that we faced in our daily basis work. Author's Response: 4/5/2005     Thanks, Sushant! These subtle persuasive skills can make a big difference in how effective a tester is.

Back to Top