This document discusses closing the loop between development and testing. It addresses whose responsibility it is to find and fix bugs, and how teams should communicate about bug status. The document advocates that quality is a shared responsibility of both developers and testers. It also promotes automating testing where possible to reduce manual effort and ensure bugs found are reproducible.
5. Why Test? Why Not?
• Why are we testing?
• What are we testing?
• Who is responsible for
testing?
• Do you want it on time
or do you want it to be
perfect?
• How do you define a
good test?
• Bugs are bound to
happen, why can’t we
just live with it?
6. Whose bug is it anyway?
• Picking teams
– Beyond Development vs. Test
• Finding bugs
– Developer, tester or customer?
• Communicating the status
– We know about it, now what?
• It’s fixed, what next?
– Likely to resurface?
7. Picking Teams
• producer
• Development
generates • non-mgmt
• business
• technical
• customer
• test
• Management
consumes • Business
• Technical
11. What’s Next?
• Where do we go from
here?
• We’ve identified :
• our teams,
• our bug spotters
• how they will be fixed
• Will we have to repeat
this during the next
iteration?
• Yes, if we don’t
document and learn
from this cycle.
• No, if we do apply these
lessons to our process.
13. Yours, Mine and Ours
Lines of code written Test Results gathered
• •
Number of bugs closed Number of bugs opened
• •
Shipping on time Shipping quality
• •
On to the next project Clearing the backlog
• •
So, what’s the common
ground?
24. 2010…
Bug to the Future
• Hierarchal work items
• Eliminating “no-
repro” bugs
• Test impact analysis
• Test prioritization
• Viewing the quality of
requirements and the
value of testing
• Reduce the manual
effort for automation-
capable tests
25. In summary
• The most important tool is communication
between dev and test.
• Quality belongs to everyone, as does lack
of.
• Automation is a good friend to have.
• Respect for your work, your colleagues,
your customers.