Monday, August 25, 2008
Books
Please read Lessons Learned in Software Testing, and Computer Software Testing. The former is a book that can be read straight through and is quite enjoyable. The latter is also quite enjoyable, but it reads more like a textbook for a class. Still, it would be worthwhile to read it straight through and refer to it as needed. There is a lot of combined wisdom and experience that can save you a lot of trouble.
On-the-fly test plans
I'm trying to encourage testing as an inquisitive, intellectually-engaged process. While test cases, test-case management software, and excel spreadsheets can be useful, they can be counter-productive if they take the place of good detective work. In my experience, they serve as a reminder of what to test, or more accurately, the things you jotted down last time you considered what you should test and jotted things down.
I wonder if, in addition to or replacing entirely a bank of static test cases, it would be better to create on-the-fly test plans/cases. This would consist of opening up a blank spreadsheet, entering all of your assumptions about what should be tested, making a test matrix, deciding what portion of those tests should be tested, and reviewing your test plan briefly with a developer who cares.
This should not be interpreted as a linear or step-by-step strategy. These are just some of the elements thrown together roughly in the order of the first occurence of each item. Ideally, a developer or customer will be available throughout the process for clarification. You'll be seen as bugging and bothering people until you uncover some miscommunicated assumptions whose discovery saves everyone a lot of trouble. You'll build a reputation for heading off trouble before it troubles others, and developers will hopefully be more willing to be interrupted to answer questions.
I wonder if, in addition to or replacing entirely a bank of static test cases, it would be better to create on-the-fly test plans/cases. This would consist of opening up a blank spreadsheet, entering all of your assumptions about what should be tested, making a test matrix, deciding what portion of those tests should be tested, and reviewing your test plan briefly with a developer who cares.
This should not be interpreted as a linear or step-by-step strategy. These are just some of the elements thrown together roughly in the order of the first occurence of each item. Ideally, a developer or customer will be available throughout the process for clarification. You'll be seen as bugging and bothering people until you uncover some miscommunicated assumptions whose discovery saves everyone a lot of trouble. You'll build a reputation for heading off trouble before it troubles others, and developers will hopefully be more willing to be interrupted to answer questions.
Oops
I accidentally deleted my blog, doh! That's ok, nobody read it yet, or at least, no one commented on it. Maybe the Google crawlers didn't catch up to it yet. In any event, here's the blog again. A whole new world, blabety blah.
Subscribe to:
Comments (Atom)