|
Testing Foundations
|
Various Writings on Software |
Everyday Scripting with Ruby (2007): Using Ruby to automate common tasks in software projects, freeing you to concentrate on what's important. Heavily hands-on.
The Craft of Software Testing (1995): Software testing "in the medium". A somewhat dated approach, written in a less spritely manner than I'd use today. Many of the ideas are still sound, but this is not how I do things today.
|
Title and Description |
HTML? | PDF? | Discussion? |
|
Methodology Work is Ontology Work
Large-scale adoption of a new methodology means "infecting" people with new ideas about what sorts of things there are in the (software development) world. (Presented at OOPSLA Onward! 2004.) |
|||
|
Behind the Screens
Using the Ruby scripting language for exploratory testing of Google's web services interface. In this paper, I attempt to make scripting seem easy and fun. No programming experience required. (First appeared in Better Software .) |
|||
|
Bypassing the GUI
Testing through the GUI is hard. Testing through a scripting interface is easier. Here's an example of testing Word through COM. (First appeared in Software Testing and Quality Engineering Magazine .) |
|||
|
Using Ring Buffer Logging to Help Find Bugs
Design patterns for using ring buffers to record information useful in debugging. Choosing what information to log. Encouraging users to send in logs. (This is only peripherally a testing paper.) (Presented at Pattern Languages of Programs 2000.) |
|||
|
A Manager's Guide to Evaluating Test Suites
(with James Bach and Cem Kaner) A subjective approach to judging the goodness of a collection of tests, together with some reasons why objective approaches aren't sufficient. (Presented at Quality Week 2000.) |
|||
|
The Tester's Triad: Bug, Product, User
How I believe testers should use bug reports, knowledge of product internals, and user descriptions. (Presented at STAR East '00.) |
HTML | ||
|
Faults of Omission
A common type of fault and how to find it. (First appeared in Software Testing and Quality Engineering Magazine .) |
HTML | ||
|
How to Misuse Code Coverage
It also talks about how not to misuse it. (Presented at Testing Computer Software '99.) |
|||
|
New Models for Test Development
Why I think the V model is harmful in test project planning. Requirements for test planning. (Presented at Quality Week '99.) |
|||
|
Working Effectively With Developers
Sometimes referred to as the "how to suck up to developers" paper. (Presented at STAR West '98.) |
|||
|
When Should a Test be Automated?
An unconventional view of the economics of test automation. (Presented at Quality Week '98.) |
|||
|
Classic Testing Mistakes
This is the paper that caused James Bach to exclaim, "Brian! I never thought you knew anything about testing before!" Our ensuing collaboration is probably due to this paper. (Presented at STAR '97.) |
HTML | Discussion | |
|
The Test Manager at the Project Status Meeting
(with Steve Stukenborg) What information should a test manager present? (Presented at Quality Week '97.) (Note on the PDF version: Steve and I were using different versions of Word. The pictures grew change bars that we couldn't get rid of. They're still understandable.) |
HTML | Discussion | |
|
Experience with the Cost of Different Coverage Goals for Testing
(Presented at Pacific Northwest Software Quality Conference '91.) |
|
Title and Description |
HTML? | PDF? | Discussion? |
|
Roadmap for Agile Testing 2004
If I were starting up an agile project, here is how I'd plan to do testing. (First appeared in Agile Times, #5) |
HTML | ||
|
Tacit Knowledge
Experts often have no explicit theory of their work. They simply perform skillfully. (First appeared in Better Software , V5 no.4) |
HTML | ||
|
Final Vocabulary
A way of understanding people who live in different worlds. (First appeared in Software Testing and Quality Engineering Magazine , V5 no.4) |
HTML | ||
|
Process and Personality
Every article on methodology implicitly begins "Let's talk about me." (First appeared in Software Testing and Quality Engineering Magazine , V4 no.6) |
HTML | ||
|
Agile Methods and Agile Testing
The implications of agile methods for testing. (First appeared in Software Testing and Quality Engineering Magazine , V3 no.5) |
HTML | ||
|
A Buyer's Guide to Code Coverage Terminology
Its terminology makes code coverage seem too complicated. Here's my attempt to simplify. |
HTML | ||
|
Normal Processes
Applying sociologist Charles Perrow's idea of normal accidents to software process design. (First appeared in Software Testing and Quality Engineering Magazine , V1 no.4) |
|||
|
Maybe Testers Shouldn't Be Involved Quite So Early
Pitfalls of involving testers in requirements analysis. (First appeared in Software Testing and Quality Engineering Magazine , V1 no.3) |
HTML | ||
|
The Testing Team's Motto
We are a service organization whose job is to reduce damaging uncertainty about the perceived state of the product. |
HTML | Discussion | |
|
Notes on Object-Oriented Testing, Part 1
The effect on fault-based test design. |
HTML | ||
|
Notes on Object-Oriented Testing, Part 2
Test design based on scenarios or use cases. |
HTML | ||
|
Testing Software That Reuses
How producers of reusable software can help their customers test. |
HTML |
Here is a set of reviews of books, articles, and web pages, organized by title. They're cross-linked for easy browsing.
I've also organized the same set of reviews according to task. From this page, you can quickly find which reviews cover works that will help you with, say, automating tests.
I used to give a half-day tutorial called "Testing for Programmers". Here are the course notes. They are PDF, 114 pages, 471K. They have a picture of a slide on the top of each page. On the bottom is what I say for that slide. I think of this as a heavily illustrated booklet, not a slide show. (I rarely get much out of looking at slides in isolation.)
The PDF conversion mostly went well. The largest glitch is that all the color went away.
The course uses a catalog that you have to download separately. It also refers to a case study of fixing a bug. You may want to read that as well.