Hi Richard,

        There are actually several commercial testing utilities for 
Windoze application development that can do automated GUI testing (one 
that comes to mind is Vermont HighTest).  A technician in my old 
department at work (this was several years ago) used it to test a 
VisualBasic GUI we made for one of our call controllers.  It had a feature 
where it could test different screen regions, windows, or controls for 
changes and could compare against expected results.

        I wouldn't suggest that automated GUI (even graphical output 
testing) is trivial, but it is possible and there are commercial examples 
out there.  It can also be done without having a person in the loop for 
regression testing.

                                                        -Dean






"Richard A. O'Keefe" <ok at cs.otago.ac.nz>
Sent by: squeak-dev-bounces at lists.squeakfoundation.org
08/05/03 08:03 PM
Please respond to The general-purpose Squeak developers list 

 
        To:     squeak-dev at lists.squeakfoundation.org
        cc: 
        Subject:        Re: GUI output testing


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.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030805/ab518eb8/attachment.htm