Comments on: Respect the Defect: Advice that will change the perception of testing http://blog.utest.com/respect-the-defect-advice-that-will-change-the-perception-of-qa/2009/06/ Software Testing Community Fri, 30 Jul 2010 06:53:12 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Bug Reporting Lessons rom Toyota: Are Your Brakes Show Stoppers? | Software Testing Blog http://blog.utest.com/respect-the-defect-advice-that-will-change-the-perception-of-qa/2009/06/comment-page-1/#comment-14992 Bug Reporting Lessons rom Toyota: Are Your Brakes Show Stoppers? | Software Testing Blog Thu, 25 Mar 2010 16:26:54 +0000 http://blog.utest.com/?p=819#comment-14992 [...] uTest blog, you may have come across a well-written post by guest blogger and uTester Joseph Ours: Respect the Defect: Advice that will change the perception of testing. The philosophy of proper defect reporting is well described by Ours, and may be a great primer for [...] [...] uTest blog, you may have come across a well-written post by guest blogger and uTester Joseph Ours: Respect the Defect: Advice that will change the perception of testing. The philosophy of proper defect reporting is well described by Ours, and may be a great primer for [...]

]]> By: Our Guest Blogger Series: 2009 Year in Review | Software Testing Blog http://blog.utest.com/respect-the-defect-advice-that-will-change-the-perception-of-qa/2009/06/comment-page-1/#comment-14674 Our Guest Blogger Series: 2009 Year in Review | Software Testing Blog Wed, 23 Dec 2009 06:22:03 +0000 http://blog.utest.com/?p=819#comment-14674 [...] Respect the Defect: Advice That Will Change the Perception of  Testing – by Joseph Ours:  Testers need to reconsider they way they report bugs – this was the position taken by Joseph Ours in his first (and hopefully not last) uTest blog post. Challenging testers to demonstrate their value by writing more clearly about the bugs they uncover (among other tactics), Joesph has sparked an interesting debate among our community. Visit the comments section to see for yourself. [...] [...] Respect the Defect: Advice That Will Change the Perception of  Testing – by Joseph Ours:  Testers need to reconsider they way they report bugs – this was the position taken by Joseph Ours in his first (and hopefully not last) uTest blog post. Challenging testers to demonstrate their value by writing more clearly about the bugs they uncover (among other tactics), Joesph has sparked an interesting debate among our community. Visit the comments section to see for yourself. [...]

]]> By: And The Winner Is… “Battle of the Search Engines” Results Are In | Software Testing Blog http://blog.utest.com/respect-the-defect-advice-that-will-change-the-perception-of-qa/2009/06/comment-page-1/#comment-14482 And The Winner Is… “Battle of the Search Engines” Results Are In | Software Testing Blog Tue, 15 Sep 2009 20:09:46 +0000 http://blog.utest.com/?p=819#comment-14482 [...] top tester prize went to Joseph Ours of Columbus, Ohio, who reported a number of highly valuable bugs and provided some outstanding [...] [...] top tester prize went to Joseph Ours of Columbus, Ohio, who reported a number of highly valuable bugs and provided some outstanding [...]

]]> By: Petter http://blog.utest.com/respect-the-defect-advice-that-will-change-the-perception-of-qa/2009/06/comment-page-1/#comment-14455 Petter Mon, 24 Aug 2009 08:12:03 +0000 http://blog.utest.com/?p=819#comment-14455 "However, I can’t see that testers, anymore than programmers, should be allowed to second guess the customer value (or lack thereof)." Well, maybe not more (although I expect a tester to have more of a helicopter view than a programmer has) but as a programmer I must say I'm glad for all input I get from users, whether they are end users or testers. A surprisingly high amount of UI and functionality decisions are at the end of the day made by the programmer, and a programmer isn't usually the best person to make these decisions... Also keep in mind that an end user who states a problem is usually incorrect in his or her description of or "solution" to a certain problem. After all, if your application has a thousand users and you get one support email, you should ask yourself how well-founded this user's views are, before you dig in. /Petter “However, I can’t see that testers, anymore than programmers, should be allowed to second guess the customer value (or lack thereof).”

Well, maybe not more (although I expect a tester to have more of a helicopter view than a programmer has) but as a programmer I must say I’m glad for all input I get from users, whether they are end users or testers. A surprisingly high amount of UI and functionality decisions are at the end of the day made by the programmer, and a programmer isn’t usually the best person to make these decisions…

Also keep in mind that an end user who states a problem is usually incorrect in his or her description of or “solution” to a certain problem. After all, if your application has a thousand users and you get one support email, you should ask yourself how well-founded this user’s views are, before you dig in.

/Petter

]]> By: Morgan http://blog.utest.com/respect-the-defect-advice-that-will-change-the-perception-of-qa/2009/06/comment-page-1/#comment-14412 Morgan Wed, 22 Jul 2009 19:30:23 +0000 http://blog.utest.com/?p=819#comment-14412 Being able to prove the customer value in everything you do is/should be a requirement for anyone working with software (probably most other fields as well). However, I can't see that testers, anymore than programmers, should be allowed to second guess the customer value (or lack thereof). Any problems found with the software should be possible to relate to the behaviour asked for by the customer in the form of requirements, acceptance tests, decided standards etc. Best regards Being able to prove the customer value in everything you do is/should be a requirement for anyone working with software (probably most other fields as well). However, I can’t see that testers, anymore than programmers, should be allowed to second guess the customer value (or lack thereof). Any problems found with the software should be possible to relate to the behaviour asked for by the customer in the form of requirements, acceptance tests, decided standards etc.

Best regards

]]> By: Max http://blog.utest.com/respect-the-defect-advice-that-will-change-the-perception-of-qa/2009/06/comment-page-1/#comment-14396 Max Fri, 03 Jul 2009 06:05:20 +0000 http://blog.utest.com/?p=819#comment-14396 Great, thanks Joseph. You worded my most "annoying" experiences as tester. This is exactly what makes the tester advance from the "bad guy" to the valuable guy. In my past experience as tester, often, when reporting a bug (with the usual description) the developers - not so PMs - tried to discuss the bug as not being one, taking the bug as a personal disgrace. - until I found the way to replace the problem with the chance (for the developer) to improve even further. Putting into the bug report values just like Joseph wrote above make such discussions disappear forever. Great, thanks Joseph.
You worded my most “annoying” experiences as tester.
This is exactly what makes the tester advance from the “bad guy” to the valuable guy.
In my past experience as tester, often, when reporting a bug (with the usual description) the developers – not so PMs – tried to discuss the bug as not being one, taking the bug as a personal disgrace. – until I found the way to replace the problem with the chance (for the developer) to improve even further.
Putting into the bug report values just like Joseph wrote above make such discussions disappear forever.

]]> By: Andy http://blog.utest.com/respect-the-defect-advice-that-will-change-the-perception-of-qa/2009/06/comment-page-1/#comment-14394 Andy Thu, 02 Jul 2009 15:01:21 +0000 http://blog.utest.com/?p=819#comment-14394 This is why it's important for all testers/QA folks to really understand the application and its users. The great QA folks I've worked with had a deep desire to get in the heads of their customers, even go on customer visits and listen to customer support calls and to read up on the industry. The PM is often very busy and doesn't have the bandwidth (or sometimes the depth) to make every decision. When QA can contribute their informed opinions, it just makes the overall product better. This is why it’s important for all testers/QA folks to really understand the application and its users. The great QA folks I’ve worked with had a deep desire to get in the heads of their customers, even go on customer visits and listen to customer support calls and to read up on the industry.

The PM is often very busy and doesn’t have the bandwidth (or sometimes the depth) to make every decision. When QA can contribute their informed opinions, it just makes the overall product better.

]]> By: Bernard L http://blog.utest.com/respect-the-defect-advice-that-will-change-the-perception-of-qa/2009/06/comment-page-1/#comment-14388 Bernard L Fri, 26 Jun 2009 16:58:29 +0000 http://blog.utest.com/?p=819#comment-14388 Excellent post Joseph! I agree with every word and would like to echo on that. Bug reports is how testers are seen & 'measured' by their colleagues. Product managers provide well-designed and detailed MRDs & PRDs. Analysts provide their analysis reports. Developers provide the actual product. We, testers, provide bug reports & periodically test results/statuses. Testers should understand the real value of such detailed test reports with references & value items and implement this on their bug reports. Developers but mostly Product managers (PMs) are the main assignees & stake holders of bug reports. PMs are usually bombarded with bug reports which they need to prioritize and assign to developers. Giving the large numbers or assigned bugs to them along with the company's pressure to submit product soon to the market, bugs which are only informative and missing the real 'juice' of such well-suggested reference and value items can be easily targeted as 'Resolve later', 'Wont fix' and off-course lowered-priority, thus rarely will be taken seriously! By supplying real reference and value items, one can provide a much clear & reasonable bug defect reporting with a real value to the stakeholders which can assist them in making the RIGHT choices when dealing with such reported bugs and most important earn great creditability. Kudos for the well detailed & influential subject & keep them coming! Cheers, Bernard. Excellent post Joseph!

I agree with every word and would like to echo on that.
Bug reports is how testers are seen & ‘measured’ by their colleagues.

Product managers provide well-designed and detailed MRDs & PRDs.
Analysts provide their analysis reports.
Developers provide the actual product.

We, testers, provide bug reports & periodically test results/statuses.

Testers should understand the real value of such detailed test reports with references & value items and implement this on their bug reports.
Developers but mostly Product managers (PMs) are the main assignees & stake holders of bug reports. PMs are usually bombarded with bug reports which they need to prioritize and assign to developers. Giving the large numbers or assigned bugs to them along with the company’s pressure to submit product soon to the market, bugs which are only informative and missing the real ‘juice’ of such well-suggested reference and value items can be easily targeted as ‘Resolve later’, ‘Wont fix’ and off-course lowered-priority, thus rarely will be taken seriously!

By supplying real reference and value items, one can provide a much clear & reasonable bug defect reporting with a real value to the stakeholders which can assist them in making the RIGHT choices when dealing with such reported bugs and most important earn great creditability.

Kudos for the well detailed & influential subject & keep them coming!

Cheers,
Bernard.

]]>