Here's a version of the plan I sent to Dave, followed by a request for help.
Target size is typical for the Pragmatic series (unit test, CVS, etc.)
I have three goals for the book:
Teach testers how to program, and program at least moderately well.
Move testers from a position of dependence to one of
sufficiency. Too often I see testers who are helpless to do a lot of
things for themselves and are cut off from lots of conversation, both
of which reinforce their peripheral position. For example, if they knew
programming, they'd both be able to ask for and receive better
Push Ruby toward being the tester's language (which is going to
require some catching up with Python and Perl in terms of
The style will be similar to
Dive Into Python:
learning by examining and building
examples. I'll make the examples as
progressive as possible.
The first example will build on a way of doing exploratory testing,
which is to bang away at the GUI while watching the log scroll along
in a nearby window and noting exceptions.
- It will start with simple IRB usage: reading from a file.
- Reading from a file with a program.
- Reading from a file that's continuously filling.
- Filtering / regexes.
- Adding a simple GUI
- Maybe making the app beep or flash when it sees something
- Different types of filters - pluggability - unit testing
- XML parsing and tree-munging
I will probably add a simple HTTP server as a way of demystifying
This is all toward the end of showing that testers are not limited to
using tools just for running
tests. They can build what they need to build.
Then I move to testing. I'll probably start with a simple introduction
to Watir (testing
that uses IE via COM). There's a possibility I'll
in the browser and has Java and Python bindings today). I'll
definitely do a web-services chapter (again, as much to demystify as
anything else). Then on to the real problem: testing a windowing
app. I prefer to test under the GUI here (actually, with web clients
too). The web services chapter and the HTTP server chapter have primed
them for that: because now it will seem to them quite unexceptional to
stick something in the app that talks some protocol and translates
remote calls into whatever below-the-GUI API is there.
It would be nice to talk jruby
for testing Java apps. I will if it seems
Last part (depending on space) is about using various tools -
whatever's out there - to do various testing-ish tasks.
So the request for help: what do you think of that? What kinds of
tasks should be covered? What tools should I talk about?