GUI automation tool (windows)
in [Python]
|
From: Lawrence D'Oliveiro on 11 Aug 2010 00:51 In message <mailman.1936.1281496277.1673.python-list(a)python.org>, Robert Kern wrote: > On 2010-08-10 21:57 , Lawrence D'Oliveiro wrote: > >> In message >> <abe9b308-db83-4ca8-a71a-12d2025a7615(a)i31g2000yqm.googlegroups.com>, Alex >> Barna wrote: >> >>> On Aug 10, 10:05 am, Lawrence D'Oliveiro >>> >>>> Can't understand the point to it. “GUI automation” is a contradiction >>>> in terms, because a GUI is designed for use by humans to do manual >>>> tasks, not ones that can be automated. >>> >>> Automating GUI is for testing. >> >> But the most egregious GUI problems are going to be with humans being >> unable to figure out how to do something, am I right? > > Possibly, but it's not the *only* important problem. Automated GUI testing > is usually a form of regression testing. You want to make sure that the > behavior of parts of the GUI did not change when you made what should be > unrelated modifications to the code. Again, that's something that primarily affects real users, when they find some function is no longer in the place where they expect it to be. You have to test with real users to find out what they think of this sort of thing.
From: Lawrence D'Oliveiro on 11 Aug 2010 00:52 In message <i3t449$7cg$1(a)reader1.panix.com>, Grant Edwards wrote: > Automated GUI intended to uncover problems in the underlying program > functionality ... That “underlying” functionality has nothing to do with the GUI, then. Why not test it directly, rather than go through the GUI? > Automated GUI testing often isn't even being used to test the program > whos GUI is being automated. It's often used to test _other_ programs > with which the GUI-automated-program interacts. Again, this sounds like it has nothing to do with the GUI per se.
From: Ben Finney on 11 Aug 2010 01:00 Lawrence D'Oliveiro <ldo(a)geek-central.gen.new_zealand> writes: > In message <i3t449$7cg$1(a)reader1.panix.com>, Grant Edwards wrote: > > > Automated GUI intended to uncover problems in the underlying program > > functionality ... > > That “underlying” functionality has nothing to do with the GUI, then. Why > not test it directly, rather than go through the GUI? Because that behaviour can be different when tested in a way that doesn't involve using the actual program's interface. The GUI is part of the program's behaviour, remember, and just about any non-trivial GUI program will have quite complex behaviour specifically in its GUI. Is the concept of testing the actual program behaviour really foreign to you? If not, what part of this concept is causing you difficulty? -- \ “Two paradoxes are better than one; they may even suggest a | `\ solution.” —Edward Teller | _o__) | Ben Finney
From: Grant Edwards on 11 Aug 2010 02:09 On 2010-08-11, Lawrence D'Oliveiro <ldo(a)geek-central.gen.new_zealand> wrote: > In message <mailman.1936.1281496277.1673.python-list(a)python.org>, Robert > Kern wrote: > >> On 2010-08-10 21:57 , Lawrence D'Oliveiro wrote: >> >>> In message >>> <abe9b308-db83-4ca8-a71a-12d2025a7615(a)i31g2000yqm.googlegroups.com>, Alex >>> Barna wrote: >>> >>>> On Aug 10, 10:05 am, Lawrence D'Oliveiro >>>> >>>>> Can???t understand the point to it. ???GUI automation??? is a contradiction >>>>> in terms, because a GUI is designed for use by humans to do manual >>>>> tasks, not ones that can be automated. >>>> >>>> Automating GUI is for testing. >>> >>> But the most egregious GUI problems are going to be with humans being >>> unable to figure out how to do something, am I right? >> >> Possibly, but it's not the *only* important problem. Automated GUI testing >> is usually a form of regression testing. You want to make sure that the >> behavior of parts of the GUI did not change when you made what should be >> unrelated modifications to the code. > > Again, that???s something that primarily affects real users, when they find > some function is no longer in the place where they expect it to be. Automated testing can detect when some function is no longer where it used to be. > You have to test with real users to find out what they think of this > sort of thing. Again, nobody's talking about using automated testing to figure out what users think. We're talking about using automated testing to make sure that rev 3.5 acts the same what that rev 3.4 did when you push button X or select menu option Y. -- Grant
From: Grant Edwards on 11 Aug 2010 02:12
On 2010-08-11, Lawrence D'Oliveiro <ldo(a)geek-central.gen.new_zealand> wrote: > In message <i3t449$7cg$1(a)reader1.panix.com>, Grant Edwards wrote: > >> Automated GUI intended to uncover problems in the underlying program >> functionality ... > > That ???underlying??? functionality has nothing to do with the GUI, > then. Why not test it directly, rather than go through the GUI? Because in many programs _there_is_no_other_way_to_test_it_directly_. Yes, that sucks. In the real world most programs suck. You've still got to test them. >> Automated GUI testing often isn't even being used to test the program >> whos GUI is being automated. It's often used to test _other_ programs >> with which the GUI-automated-program interacts. > > Again, this sounds like it has nothing to do with the GUI per se. Exactly! That's what we've been trying to explain. Automating a GUI isn't done to test how well the GUI works for real users. It's done mainly for two purposes: 1) Regression testing to make sure that the GUI's behavior (good, bad, or indifferent) hasn't changed since the previous revision. 2) To test the functionality underlying the GUI. |