
PEAK PERFORMANCE
Software testing is improved by good bug reporting
Scott Barber 07.03.2008
Rating: -4.33- (out of 5)




|
I recently completed (successfully, I might add) the second of the Association for Software Testing's all online, free to members Black Box Software Testing course. Each of these courses is four weeks in length. I've been involved with this program since years before it became a program, and I am an instructor for the first course in the series, called Foundations. For this course, called Bug Advocacy, I was a student.
Bug Advocacy focuses on the skills and concepts needed to compose high-quality, easily understood, appropriately compelling and well organized defect reports. I know, it sounds pretty boring to me too, but it was anything but boring. These classes are designed so that you watch recorded lectures (in this class the lecturer is Cem Kaner), answer some quiz questions (to make sure you watched the lectures), participate in class discussions, do both individual and group projects (in this class the project centered around evaluating and enhancing unconfirmed OpenOffice bug reports), peer reviewing one another's assignments, and taking a far-from-trivial closed-book essay exam. All in all, I spent about 40 hours participating in the class over the four week period.
There was one idea in particular from the class that I found absolutely brilliant and wanted to share with you. Below is actually a very lightly edited version of my an
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
');
// -->

swer to one of the exam questions asking us to describe a six-factor approach to bug reporting that Cem remembers using the mnemonic "RIMGEA." If you are a regular reader of mine, you know that I have a fondness for mnemonic devices, but that's not what I thought was so great about the approach. What I think is brilliant is that this approach isn't just about writing a good bug report, it's also about making sure you do the right testing after you find a bug to enable you to write a good bug report. Take a look -- you'll see what I mean.
You simply aren't going to be able to apply these factors to your bug reporting without having done some good testing first. For whatever reason, I'd never thought of using bug reporting as a method of self-assessing the quality of my testing, but after taking this course I'm pretty confident that I'll be doing exactly that from now on.
(Footnote: For more information about the Association for Software Testing (AST) and the training courses they offer, visit their website at http://www.associationforsoftwaretesting.org.)
----------------------------------------
About the author: Scott Barber is the chief technologist of PerfTestPlus, vice president of operations and executive director of the Association for Software Testing and co-founder of the Workshop on Performance and Reliability.
 |

|
|
 |
|
 |