[qmtest] The state of GUI

[eichin at metacarta.com]

> far as I am concerned as a user, I have indeed mostly been working with
> custom databases that are non-modifiable. I'v only recently started to use
> the GUI.

When I first started with QMtest, the gui was a usefully narrow way to
poke at something and expect that whatever I poked at would do
*something* reasonable.  Eventually I wrapped another layer of
homebrew automation[*] around it all, though, and I don't really see any
way *any* GUI would help there, though I suspect that if I were using
QMtest for something narrower, or had a better vocabulary of tests
that a non-programmer[**] could come up with new combinations for, it
would get more use.
			_Mark_ <eichin at metacarta.com>



[*] That's mostly because my testing problem is more at a systems
level and I stretched QMtest a *lot* to solve it; looking back, I need
abstractions that would get in the way in more conventional software
test situations.  (It's a credit to qmtest and python that I was
*able* to stretch it that far :-) and nothing else was, or is,
anywhere close.)

[**] Not that I believe in non-programmer testers anymore.
"exploratory" testing (ie. banging on things) is something you do in
order to come up with new automation.  Microsoft's SDE/T model makes a
lot of sense to me now...