In the world of open source, a bug is any defect that needs to be fixed -- whether in code, in process, in documentation, or in some other deliverable. A wonderful benefit of working in an open source community is that you don't even need to be right about identifying bugs. All you need to be able to do is articulate the fact that something either is wrong, or feels wrong, and show someone else how they can see the same thing that you do.
What are some simple examples of bugs?
Eric S. Raymond wrote in "The Cathedral and the Bazaar" that "given enough eyeballs, all bugs are shallow." Everything has bugs, and this chapter covers the best practices around dealing with bugs in an open source project. We will discuss bug tracking tools: how they work, and why they matter. We will discuss the various views about what "good bugs" look like. We will talk about how to verify bugs, and why that's so important. Finally, we will take a brief look at Quality Assurance as a discipline, and explain how it is more than simply "bug management."
FIXME -- a couple examples of different types of bugs (including some non-code bugs - design tickets, infra tickets, process tickets, etc.)
Remember the pyramid of contribution. FIXME -- refer back to wherever we place this section.
This will be a typical story about how someone finds a bug, and how everything goes wrong when she tries to report it, and how it could and should go so much more smoothly. We will define terms like "bug tracker" and "bug reporter" and so forth along the way.
A. Why a bug tracker matters
1. Organization of defects, enhancements, and todos.
2. How do we designate between a bug tracker and a project management tool?
3. Enables collaboration.
B. Overview: trac
C. Overview: bugzilla
D. How to find other bug tracking software out there
A. The bug exists in the latest build.
B. You have reproduced the bug multiple times in a consistent fashion.
C. Enough information, but not too much. ???
D. Look at the things bugzilla asks for.
E. A good bug has a reporter who will help the developer get it fixed.
1. This grows with experience.
2. Opportunity for growth in the pyramid.
Exercise: Is this a good bug?
A. Read a set of bug reports. What is good/bad? How would you modify them to improve them?
A. EXERCISE: Replicating Bugs. Pick three NEW bugs in your chosen project, and try to replicate them in your latest version. If you succeed, note it in the bug. If you cannot replicate, note that too. Provide as much info as possible.
VIII. Debugging
A. How to read code. Is this something that can reliably be put into a chapter? FIXME. There's always the obvious stuff, like grepping the code for text of errors generated, putting in logic checkpoints to narrow the scope of the problem, and so forth. Do some research on good materials here.
B. Exercise: Finding the bug. Select a bug that has been previously identified as replicable, dig into the codepath, find the lines of code that cause the error, and update the bug with a statement of where, exactly, the bug is.
C. Exercise: Fixing the bug. This can be the hardest part, but give it a shot. In the bug that was just found, fix it to see if it solves the problem on your local machine, and then submit that fix as a patch to the developers, either as an attachment to the bug or as an email to the developer mailing list.
A. The unique role of a bugmaster. Do you need one? How a bugmaster, or a role like it, can fit into the contribution pyramid. We may also want to cop to the notion that bugfixing in open source projects often isn't very good, but make the point that proprietary products are often much worse -- you just don't know it.
B. Case study: GNOME bugmasters
C. An important point -- maybe a project you care about doesn't yet have a bugmaster! Maybe it should! Maybe that person could be you!
To make a simple sports analogy, the QA team is the goalkeeper -- the last line of defense before a product reaches its intended audience.
FIXME -- I need some way to say "product" and have people realize it can be anything. Probably just define that above once.
product, or a project, or... "before the end user experiences what you were working on?"
B. How it is more than just dealing with bugs.
C. Some of the most common types of testing.
I. Feature testing -- does something new work in the manner required/specified?
II. Regression testing -- do the things that used to work still work?
IV. Smoke testing -- do the most basic or critical-path functions work? Can it install, for instance?
V. Usability testing -- how easy is it to use? Does it make sense? What does someone who has never used the product before do when they sit down in front of it?
VI. Load testing -- Does it scale? What happens if 500 people try to use it at the same time? What about 5,000?
FIXME -- branch a lot of these short definitions out to existing references (books, blogs, etc) where students can learn more.
* Identify who, in your bugtracker, has more NEW bugs assigned to them than anyone else. Triage those NEW bugs for that individual: replicating, finding duplicate bugs that match, requesting more information, etcetera. Once you've triaged a bug, move that bug from "NEW" to "ASSIGNED". See how many bugs you can move along in two hours.
* Find the oldest 10 bugs in your project's bug tracker. Try to replicate those bugs in the very latest version of the software. Does the bug look the same? Probably not! If the bug no longer occurs, close it! If it does occur, validate in the bug that it continues to occur!
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.