GUI output testing

Richard A. O'Keefe ok at cs.otago.ac.nz
Wed Aug 6 00:03:55 UTC 2003


Julian Fitzell <julian at beta4.com> replied.
His reply included:
	There can still be problems of course but I think you're going
	to need a human at the end anyway.

That's really the issue.  How often do you need that human, for how long,
and doing what?

Event record/playback means that we can handle the input side of a GUI
test case without inflicting RSI on too many people.

For usability tests, you need a handful of users trying to solve some
real(istic) problems.  But when you are doing regression testing, you
might want to have the visual output checked, again, and again, and
again.

In the case of Morphic, it's easy to see how you could easily add
some kind of #dumpXmlOutlineOn: aStream message to Morphs which would
store say morph type, bounding box, foreground and background colour,
and children, with morphs that hold values dumping their value as well.
That way you could periodically save outline snapshots, and then compare
them with expected snapshot.  This wouldn't be as good as having someone
look at it, but you could check what data had changed and whether things
overlapped that shouldn't and so on.  And you could do it *without*
modifying the application logic, which is a plus.

The student in question was telling me about a commercial project he'd
worked on where their testers spent *hundreds* of hours starting at
screens, and he was concerned that (a) this wasn't a very nice thing
to do to people and (b) it wasn't all that effective at QA anyway.
(Of course the project didn't use Squeak or any other Smalltalk.)
He wanted to know if there was anything better, and I thought that if
there was, some Squeaker would be sure to know.



More information about the Squeak-dev mailing list