tag:blogger.com,1999:blog-8951904624959546499.post8747603720224265453..comments2024-02-22T05:36:59.121-05:00Comments on Test This Blog - Eric Jacobson's Software Testing Blog: Look Before You Log – Part 2Eric Jacobsonhttp://www.blogger.com/profile/08216361684596485033noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-8951904624959546499.post-75631824619179745492013-09-14T07:43:27.121-04:002013-09-14T07:43:27.121-04:00Hi,
Nice one!You have provided good options to red...Hi,<br />Nice one!You have provided good options to reduce duplication, Even I agree with your view completely.Got some new ideas as well through the comments by Camal.<br /><br />Will practice it, Thanks a lot for sharing such important tips to become more successful in my work. QA Testerhttp://proitonlinetraining.comnoreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-73876332857946942172013-02-11T11:44:53.087-05:002013-02-11T11:44:53.087-05:00Camal Cakar,
In my company we use a pattern like...Camal Cakar,<br /><br /><i> In my company we use a pattern like this : "ScreenOfTheApplication/Function/BugDescription"</i><br /><br />That's awesome. I love that pattern.<br /><br /><i>You talked in the end of your post about that a tester can recognize that a bug was already there and fixed. But what about new testers.</i><br /><br />I was trying to say, in general, testers can tell if a newly discovered bug is in production or just in the test environment. You're right, new testers may not be as good at this.<br /><br />Thanks for the kind comments! I had an awesome visit to Munich 2 years ago. Great country. Drink a Spaten for me.Eric Jacobsonhttps://www.blogger.com/profile/08216361684596485033noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-37986431141352665302013-02-11T11:31:02.048-05:002013-02-11T11:31:02.048-05:00bug4tester, I just made up the 120-Second-Dupe-Bug...bug4tester, I just made up the 120-Second-Dupe-BugReport-Search heuristic. I picked 120 seconds b/c my norm is < 120 seconds. I called it a "heuristic" on purpose. It's fallible. Based on the context, I may take longer than 120 seconds. But for most normal situations, 120 seconds is right for me.<br /><br />I've just started using a cool free tool called AutoHotkey. It lets you automate basic windows tasks and assign them to shortcuts. Check it out.Eric Jacobsonhttps://www.blogger.com/profile/08216361684596485033noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-71148503100857627932013-02-11T04:43:27.156-05:002013-02-11T04:43:27.156-05:00Hi Eric,
great and interesting post about this top...Hi Eric,<br />great and interesting post about this topic.<br /><br />I really like to be specific as possible at the bug title to avoid confusion. In my company we use a pattern like this : "ScreenOfTheApplication/Function/BugDescription". All testers follow this guideline and it is easy to spot where to look at while verifying a bug (we have a huge application).<br /><br />Due to this approach we save a lot of time and confusion within the team because we can check very fast if that bug is a duplicate or not. But I also know the other side when the team is talking for hours about if two bugs are one and the same.<br /><br />But we also can´t avoid it all of the time.<br /><br />Great advice to check if our bug tracker can search for duplicates. Maybe there is a option like that. <br /><br />I personally like to track "all" bugs. I want the whole history. You talked in the end of your post about that a tester can recognize that a bug was already there and fixed. But what about new testers. They don´t know the history at all.<br /><br />Also I add all founded/fixed bugs in my regression test. I encountered a lot of bugs which where fixed but than after some weeks where again in our software. So I test everything again.<br /><br />Also bugs that were fixed "on the fly" are part of my list. It is a lot of work, but I like to come clean on my work :)<br /><br />Great post, great blog. You have a new reader on this one ;)<br /><br />Greets from germany and I wish you a good start into the week.<br /><br />Chéers,<br />CamalAnonymoushttps://www.blogger.com/profile/14309247223736967637noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-72015589272443796842013-02-08T23:11:19.020-05:002013-02-08T23:11:19.020-05:00How large is the project Team? Would triage meeti...How large is the project Team? Would triage meetings within the QA Team prevent a lot of this? If I was on a large Team I think it's important to know and understand where the defects are and who's work on what feature or functionality (I do understand there could be a trickle down impact for same defects not always related to the specific area or functionality).<br /><br />I think a Team cannot be successful with unless a periodic review planned. This would also be important as defects are remediated and sent back to QA. the Team needs to know.<br /><br />Thanks,<br />- Ryanrmlamonthttps://www.blogger.com/profile/12482264627484805199noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-89023107991656277322013-02-08T23:09:14.187-05:002013-02-08T23:09:14.187-05:00How large is the project Team? Would triage meeti...How large is the project Team? Would triage meetings within the QA Team prevent a lot of this? If I was on a large Team I think it's important to know and understand where the defects are and who's work on what feature or functionality (I do understand there could be a trickle down impact for same defects not always related to the specific area or functionality).<br /><br />I think a Team cannot be successful with unless a periodic review planned. This would also be important as defects are remediated and sent back to QA. the Team needs to know.<br /><br />Thanks,<br />- Ryanrmlamonthttps://www.blogger.com/profile/12482264627484805199noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-50098655779586180072013-02-08T02:07:02.338-05:002013-02-08T02:07:02.338-05:00can u share the template u use for bug reporting?can u share the template u use for bug reporting?Srinivas Kadiyalahttps://www.blogger.com/profile/04702798081842391077noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-14011685979912503762013-02-08T01:59:24.884-05:002013-02-08T01:59:24.884-05:00First of all, thank you Erick for your time to wri...First of all, thank you Erick for your time to write another great post. I got really useful ideas from your response:<br />• 120-Second-Dupe-BugReport-Search heuristic<br />(Actually I haven’t heard it before, but I like that. Definitely will try this one. I just have a question for myself, why 120 seconds? Is it the max amount of time to make a good decision? Why not 240 seconds.? Maybe there are 3000 bugs with different titles and components where I need more time to search and remember)<br />• Can you use keyboard shortcuts or assign hotkeys to dupe bug report searches? <br />(That one also great, I’ll try it.)<br /><br />Thanx again :)<br />Anonymousnoreply@blogger.com