Because breaking things is a path to learning.
It seems that there is a QA mindset, and developer mindset, and rarely the twain do meet. The QA is concerned with How, as in, "How can I make this program crash, that the developer may reproduce it?"
The developer is concerned with Why, as in, "Why did the program crash, that I may fix it?" For the developer, finding a bug is annoying, possibly frustrating. There is trust in the QA to make all the bugs known in time.
For the QA, finding a bug is joyful, like describing a pattern or a challenge. Finding a crash that reproduces is praise-worthy. There is trust in the developer that a timely, well-described bug can be fixed.
Adopting the QA mindset, one may find that all the problems of life are easier to describe. Problems become "bugs in your life." What are the steps of a problem? Who is affected? Is there a 'workaround?' Does this problem relate to other 'bugs'?
What is the actual outcome, and How does that differ from your expectations? What would a solution look like?
After that, creating a solution is just a matter of curiosity. Naturally, developers and teachers will get involved when one begins to ask Why. For edification, simply walk up to a developer and ask, "Why is this broken?"
Why QA? Because the more one understands how to break something, the greater one's understanding of how it works.
See also: Important Words in Quality Assurance.
Sunday, October 02, 2005