First page Back Continue Last page Overview Graphics
Step 0: educate developers about what the QA team is trying to do.
Step 0: educate developers about what the QA team is trying to do.
- True even if there isn't a QA team yet :)
Step 1: find out what developers are trying to do
Step 2: sort bugs so that bugs that impact those goals are identified and easy for developers to find
Step 3: communicate what you've found, and go back to 0
Notes:
This is the step-by-step QA cooking guide to the previous goals :)
Step 0: 'we're not trying to step on your toes, we're trying to help you out, let us know what you think we can do.' This is a huge difference from proprietary software QA- Jim said last night 'QA has all the power.' It turns out that if free software hackers don't like you, you have 0 power.
Step 1: 'is your focus performance? Usability? Accessibility? Stability?' [For what it's worth, GNOME still isn't 100% sure where it's going here. So the QA team mostly still focuses on the unambigous goals of stability and correctness.]
Step 2: Can a developer quickly find a list of bugs they should work on next? Additionally, can a reporter find bugs? [Note: this step, sadly, never ends. ;) important to remember here that well-managed volume can trump perfection.
Step 3: tell them- 'you're X bugs from your goal', and start the cycle again