Home > Archive > Software Testing > December 2007 > Using GUI Scripting for automated testing?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Using GUI Scripting for automated testing?
|
|
| Peter Olcott 2007-11-24, 10:27 pm |
| http://www.seescreen.com/Benefits.html
I just completed the design of a system that enables a
computer program to automatically operate the Graphical User
Interface, using fewer steps than alternative systems, and
without requiring the programmer to learn a new programming
language.
The primary benefit of this system over all competing
systems is that it can automatically operate virtually any
aspect of any GUI interface. Other systems can not
automatically operate custom GUI controls that do not
programmatically expose their state.
I was thinking that this system would be quite useful for
automated GUI testing for the cases where existing tools can
not function. What are your thoughts on this?
| |
| zerble 2007-11-26, 7:29 pm |
| On Nov 24, 1:44 pm, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
> http://www.seescreen.com/Benefits.html
>
> I just completed the design of a system that enables a
> computer program to automatically operate the Graphical User
> Interface, using fewer steps than alternative systems, and
> without requiring the programmer to learn a new programming
> language.
>
> The primary benefit of this system over all competing
> systems is that it can automatically operate virtually any
> aspect of any GUI interface. Other systems can not
> automatically operate custom GUI controls that do not
> programmatically expose their state.
>
> I was thinking that this system would be quite useful for
> automated GUI testing for the cases where existing tools can
> not function. What are your thoughts on this?
Adding OCR to a good scripting language can be interesting, but it's
hard to see how an OCR-only approach can accomplish much.
I don't believe your statement "using fewer steps than alternative
systems, and without requiring the programmer to learn a new
programming language." is attainable while still producing a robust
test automation system. I've seen too many of these "script-less"
system that don't live up to the promise.
Other tools (such as Eggplant) have taken this OCR-based approach
already. They appear to be mildly successful in a small segment, but
don't make any inroads into the overall test automation market.
If you had a publicly-available trial download, it would be simpler to
provide a more thorough analysis.
| |
| Peter Olcott 2007-11-26, 7:29 pm |
|
"zerble" <joe.strazzere@gmail.com> wrote in message
news:fa6c15ef-f4e9-425d-b86e-40c3126c9001@s19g2000prg.googlegroups.com...
> On Nov 24, 1:44 pm, "Peter Olcott" <NoS...@SeeScreen.com>
> wrote:
>
> Adding OCR to a good scripting language can be
> interesting, but it's
> hard to see how an OCR-only approach can accomplish much.
>
> I don't believe your statement "using fewer steps than
> alternative
> systems, and without requiring the programmer to learn a
> new
> programming language." is attainable while still producing
> a robust
> test automation system. I've seen too many of these
> "script-less"
> system that don't live up to the promise.
>
It uses fewer programming steps because the GUI Objects are
defined at very high levels of abstraction.
It is not script-less. It uses whatever language the
programmer already knows as its scripting language. There
are two software components that are added to these
languages, using ActiveX/COM as the interface. These two
components:
(1) SeeScreen OCR like recognizer
(2) GuiCommander scripting framework,
provide all of the functionality.
> Other tools (such as Eggplant) have taken this OCR-based
> approach
> already. They appear to be mildly successful in a small
> segment, but
> don't make any inroads into the overall test automation
> market.
I am aware of this product, and carefully studied this
product. Initially I thought that they might have been
infringing my patent. The system that I just finished
designing has tremendous advantages over their system.
The most significant advantage is that it can accomplish the
same results in 500% fewer programming steps. Another
advantage is that it can automatically operate the GUI
interface of applications that their system and every other
system are incapable of automating.
>
> If you had a publicly-available trial download, it would
> be simpler to
> provide a more thorough analysis.
Of course. I just finished the design. It will be a while
before a functional system is available for public review.
The purpose of this posting is to get a rough estimate of
the market potential for a product with the benefits that
have been defined.
| |
| zerble 2007-11-26, 7:29 pm |
| On Nov 26, 11:06 am, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
> It uses fewer programming steps because the GUI Objects are
> defined at very high levels of abstraction.
Right. Can you show an example of what you mean by those words? This
is pretty much what they all say.
> It is not script-less. It uses whatever language the
> programmer already knows as its scripting language. There
> are two software components that are added to these
> languages, using ActiveX/COM as the interface. These two
> components:
> (1) SeeScreen OCR like recognizer
> (2) GuiCommander scripting framework,
> provide all of the functionality.
Ah. So your tool is designed for programmers then?
And testers are expected to already know/use a language?
>
> I am aware of this product, and carefully studied this
> product. Initially I thought that they might have been
> infringing my patent. The system that I just finished
> designing has tremendous advantages over their system.
>
> The most significant advantage is that it can accomplish the
> same results in 500% fewer programming steps.
500% fewer? Can you provide an example which shows this?
> Another
> advantage is that it can automatically operate the GUI
> interface of applications that their system and every other
> system are incapable of automating.
Again, this is easy to say, but without an example, it's hard to
believe.
> Of course. I just finished the design. It will be a while
> before a functional system is available for public review.
> The purpose of this posting is to get a rough estimate of
> the market potential for a product with the benefits that
> have been defined.
Yup. Hard to tell if there's any market potential without a lot mre
details.
Good luck.
| |
| Peter Olcott 2007-11-26, 7:29 pm |
|
"zerble" <joe.strazzere@gmail.com> wrote in message
news:9c151ea8-65f1-4b0b-ace3-c40139eb5cba@w40g2000hsb.googlegroups.com...
> On Nov 26, 11:06 am, "Peter Olcott" <NoS...@SeeScreen.com>
> wrote:
>
>
> Right. Can you show an example of what you mean by those
> words? This
> is pretty much what they all say.
I have not filed a patent on this yet, so I must be somewhat
vague. The level of abstraction is at the same level as a
human user, or higher.
>
>
> Ah. So your tool is designed for programmers then?
> And testers are expected to already know/use a language?
The primary benefit of my system is that it can
automatically operate the Graphical User Interface in those
cases where no other tool can function. Eventually I could
provide a robust environment where complex sequences could
be specified without programming.
>
>
> 500% fewer? Can you provide an example which shows this?
Not until after I file my next patent.
>
>
> Again, this is easy to say, but without an example, it's
> hard to
> believe.
It is not a matter of believing it is a matter of
comprehending. My system can determine the state of the
graphical user interface entirely based on the state of the
display screen pixels. The SeeScreen OCR like technology
allows programs to see what is on the Screen. The
GuiCommander technology allows programs to understand the
meaning of what SeeScreen sees.
This enables graphical user interfaces that do not
programmatically expose their state, to be automatically
operated. What I am hoping for in this posting is a list of
the cases where automated testing is not possible because
the GUI can not be automatically operated. I already know
that there are some custom GUI controls that can not be
operated. I also heard that Java Swing does not expose its
programming state. I am looking for more examples of this.
>
>
> Yup. Hard to tell if there's any market potential without
> a lot mre
> details.
>
> Good luck.
If I don't get enough feedback from this posting, I will
file my next patent and provide another posting with more
details.
| |
| zerble 2007-11-26, 7:29 pm |
| On Nov 26, 12:14 pm, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
> "zerble" <joe.strazz...@gmail.com> wrote in message
> I have not filed a patent on this yet, so I must be somewhat
> vague. The level of abstraction is at the same level as a
> human user, or higher.
I see. Looking at your web site, it does appear that you are
attempting to set up patent protection, rather than to offer a real
product.
> The primary benefit of my system is that it can
> automatically operate the Graphical User Interface in those
> cases where no other tool can function.
Interesting claim, but it sounds like marketing, rather than
technology.
Can you point to a real-world example of a "case where no other tool
can function"?
>
> Not until after I file my next patent.
Ok.
>
>
> It is not a matter of believing it is a matter of
> comprehending.
I beg to differ. Anyone can write words indicating that they can do
what nobody else can do.
It would be better to show us a link to a GUI which cannot be
automated by any other tool. That way, we could try some of our
"other tools", and see for ourselves that you have come up with
something interesting.
> If I don't get enough feedback from this posting, I will
> file my next patent and provide another posting with more
> details.
Sounds good. Good luck, Peter.
Let us know when you have something that can actually be checked out
and tested against the GUI of our own applications.
If it's all you claim it to be, I'd be happy to try it and report on
its benefits.
| |
| Peter Olcott 2007-11-26, 7:29 pm |
|
"zerble" <joe.strazzere@gmail.com> wrote in message
news:9e5183d4-c01f-45cf-b61a-9b15289322f8@e1g2000hsh.googlegroups.com...
> On Nov 26, 12:14 pm, "Peter Olcott" <NoS...@SeeScreen.com>
> wrote:
>
>
> I see. Looking at your web site, it does appear that you
> are
> attempting to set up patent protection, rather than to
> offer a real
> product.
Not at all. Since I am currently the sole individual
progressing this technology, I must take things one step at
a time. The first commercial product requires a little more
development before its completion. It will be based on the
working prototype demonstrated on this page:
http://www.seescreen.com/Unique.html
The link above shows the actual results from a working
prototype of the SeeScreen technology. This will probably be
the first commercial product offering. GuiCommander is the
best use of the SeeScreen technology will be the next
product offering. The design of GuiCommander is complete,
and the development will proceed quickly.
>
>
> Interesting claim, but it sounds like marketing, rather
> than
> technology.
> Can you point to a real-world example of a "case where no
> other tool
> can function"?
Here is a good link it is an article by Linda Hayes,
entitled "An Ingenious Solution" If the link changes the
article can be found using the following keyword search in
google: [ingenious solution linda hayes]
http://www.stickyminds.com/sitewide...L&ObjectId=6408
This article extensively discusses this problem as it
directly relates to automated testing.
>
>
> Ok.
>
>
> I beg to differ. Anyone can write words indicating that
> they can do
> what nobody else can do.
>
> It would be better to show us a link to a GUI which cannot
> be
> automated by any other tool. That way, we could try some
> of our
> "other tools", and see for ourselves that you have come up
> with
> something interesting.
>
I was hoping to get more feedback of this sort from this
posting. All That I currently have is the article that I
posted, and the expert opinion of several expert windows
programmers.
I don't yet have a good estimate of the frequency that this
problem arises. This problem (that MS windows does not
expose enough information for effective GUI scripting) is
common knowledge in the MS windows programmer community.
>
> Sounds good. Good luck, Peter.
>
> Let us know when you have something that can actually be
> checked out
> and tested against the GUI of our own applications.
>
> If it's all you claim it to be, I'd be happy to try it and
> report on
> its benefits.
| |
| Atif Memon 2007-11-26, 10:23 pm |
|
Sounds interesting. Some more details would be needed to answer
your question.
But such a technology would be very useful. It could be interfaced
with automated tools to "generate" the test cases -- please see
http://guitar.cs.umd.edu
thanks
-atif
| |
| Peter Olcott 2007-11-26, 10:23 pm |
|
"Atif Memon" <atif@cs.umd.edu> wrote in message
news:Pine.GSO.4.64.0711262120100.29031@loompa...
>
> Sounds interesting. Some more details would be needed to
> answer your question.
>
What specific instances of graphical user interfaces (that
you are directly aware of) are either extremely difficult or
impossible to test because there is no way to automatically
operate them?
> But such a technology would be very useful. It could be
> interfaced with automated tools to "generate" the test
> cases -- please see http://guitar.cs.umd.edu
This should not be a problem since the bi-directional
interface to and from the system is based on ActiveX. MS
Windows components that are based on ActiveX, can interface
with the greatest number other systems with the maximum
flexibility possible.
>
> thanks
> -atif
>
>
| |
| Shrinik 2007-11-27, 4:43 am |
| Did you try this with web apps - HTML based GUI? Have you tried
ripping controls from a web application
Shrini Kulkarini
http://shrinik.blogspot.com
| |
| Vladimir Trushkin 2007-11-27, 8:21 am |
| On Nov 26, 6:06 pm, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
> Of course. I just finished the design. It will be a while
> before a functional system is available for public review.
> The purpose of this posting is to get a rough estimate of
> the market potential for a product with the benefits that
> have been defined.- Hide quoted text -
I am not sure this news group is the right place to do such a study
Despite your product addresses the biggest problem of the to date
automation -- custom controls -- I am still not sure this is
theoretically possible to use objects on such a high level of
abstraction that no human being can write the code that will violate
all the assumptions, and thus making the approach you have chosen
unfeasible.
Not seeing any details of your breakthrough invention I cannot decide
whether or not I would by such a tool. But if it really works with
anything about GUI without a pain of additional Test API programming I
will surely look into it. If it just takes 5 times less lines to write
test code I would probably keep the existing system because we already
have tons of tests written in it and developed libraries that allow us
writing a more compact and maintainable code. Converting those tests
in a new tool would be horribly painful.
----
Best Wishes,
Vladimir
| |
| Peter Olcott 2007-11-27, 10:24 pm |
|
"Shrinik" <Shrinik@gmail.com> wrote in message
news:23f0038a-51ad-4357-883d-c94afcc7ee4c@i12g2000prf.googlegroups.com...
> Did you try this with web apps - HTML based GUI? Have you
> tried
> ripping controls from a web application
>
> Shrini Kulkarini
> http://shrinik.blogspot.com
I know that it will work with any GUI interface, HTML
included. I don't know what you mean by ripping.
| |
| Peter Olcott 2007-11-27, 10:24 pm |
|
"Vladimir Trushkin" <Vladimir.Trushkin@gmail.com> wrote in
message
news:61afdc16-5993-4045-b253-f41cd4d88aa5@p69g2000hsa.googlegroups.com...
> On Nov 26, 6:06 pm, "Peter Olcott" <NoS...@SeeScreen.com>
> wrote:
>
>
> I am not sure this news group is the right place to do
> such a study
I guess that I will have to wait and see. It would seem to
at least be a good place to start.
>
> Despite your product addresses the biggest problem of the
> to date
> automation -- custom controls -- I am still not sure this
> is
> theoretically possible to use objects on such a high level
> of
> abstraction that no human being can write the code that
> will violate
> all the assumptions, and thus making the approach you have
> chosen
> unfeasible.
>
I am not sure what you are saying here. The specific way
that I have divided up the complexity of automating GUI
controls would make it quite easy to automatically operate
most any GUI control with complete reliability, and at a
very high level of abstraction.
> Not seeing any details of your breakthrough invention I
> cannot decide
> whether or not I would by such a tool. But if it really
> works with
> anything about GUI without a pain of additional Test API
> programming I
> will surely look into it. If it just takes 5 times less
> lines to write
> test code I would probably keep the existing system
> because we already
> have tons of tests written in it and developed libraries
> that allow us
> writing a more compact and maintainable code. Converting
> those tests
> in a new tool would be horribly painful.
It would be possible to automatically convert test suites
from one system into my system.
>
> ----
> Best Wishes,
> Vladimir
| |
| Shrinik 2007-11-27, 10:24 pm |
| >>>>This enables graphical user interfaces that do not
programmatically expose their state, to be automatically
operated. What I am hoping for in this posting is a list of
the cases where automated testing is not possible because
the GUI can not be automatically operated.
In some cases it is feasibility that prevents automation and other
cases, it is cost and economic consideration of owning (and
maintaining) automation solutions.
Test design, type of information that you would like to extract from
the application by and large decide what percentage of automation is
"feasible" and what percentage is "economically" viable.
Automated testing (automated test execution in real terms) is not
possible on following situations:
1. Tests are designed such way that dyanamic observations and
manipulation need to be done (entire test logic is not known very
clearly in advance). Or respond and analyse unexpected events during
automated execution - In short those tests that require human
intelligence and intervention, can not automated with respect to
execution.
2. From a technical feasibility perspective, I can see that many
custom controls will not allow programatic manipulation at run time to
execute actions on the application GUI. This is becoming more relevant
in web app space where providing "rich" and "desktop app" type user
experience on web (likes of AJAX) is becoming imporatant. As a result
GUI's are becoming more user friendly and less "automation/
programming" friendly.
3. Tests that require extensive data setup and clean up requirements,
those that require verification accross multiple systems, application
shutdown/start up kind of operations.
4. There are situations where even though automation technically
feasible but economically not viable to higher maintenance costs of
the automation code as application under test, undergoes changes in
GUI.
Shrini
| |
| Peter Olcott 2007-11-27, 10:24 pm |
|
"Shrinik" <Shrinik@gmail.com> wrote in message
news:4b812c3e-f173-4864-a248-013db578ac79@i29g2000prf.googlegroups.com...
> programmatically expose their state, to be automatically
> operated. What I am hoping for in this posting is a list
> of
> the cases where automated testing is not possible because
> the GUI can not be automatically operated.
>
> In some cases it is feasibility that prevents automation
> and other
> cases, it is cost and economic consideration of owning
> (and
> maintaining) automation solutions.
>
> Test design, type of information that you would like to
> extract from
> the application by and large decide what percentage of
> automation is
> "feasible" and what percentage is "economically" viable.
>
> Automated testing (automated test execution in real terms)
> is not
> possible on following situations:
>
> 1. Tests are designed such way that dyanamic observations
> and
> manipulation need to be done (entire test logic is not
> known very
> clearly in advance). Or respond and analyse unexpected
> events during
> automated execution - In short those tests that require
> human
> intelligence and intervention, can not automated with
> respect to
> execution.
>
> 2. From a technical feasibility perspective, I can see
> that many
> custom controls will not allow programatic manipulation at
> run time to
> execute actions on the application GUI. This is becoming
> more relevant
> in web app space where providing "rich" and "desktop app"
> type user
> experience on web (likes of AJAX) is becoming imporatant.
> As a result
> GUI's are becoming more user friendly and less
> "automation/
> programming" friendly.
My system should be able to automatically operate most any
custom GUI control that can be conceived. It could even play
fast paced video games (that expose nothing of their
internal state) and win these games. I can foresee no
aspect of any GUI control that can not be easily
automatically operated using my technology.
>
> 3. Tests that require extensive data setup and clean up
> requirements,
> those that require verification accross multiple systems,
> application
> shutdown/start up kind of operations.
>
> 4. There are situations where even though automation
> technically
> feasible but economically not viable to higher maintenance
> costs of
> the automation code as application under test, undergoes
> changes in
> GUI.
Eventually, I expect my system to require far fewer steps in
deriving automation test scripts than any other system. Many
of the details of this have been fully elaborated. The
current design may have already achieved this, I have not
yet taken the time to carefully examine every alternative
system.
>
> Shrini
| |
| zerble 2007-11-27, 10:24 pm |
| On Nov 26, 1:31 pm, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
> The first commercial product requires a little more
> development before its completion. It will be based on the
> working prototype demonstrated on this page:
> http://www.seescreen.com/Unique.html
> The link above shows the actual results from a working
> prototype of the SeeScreen technology.
I see a page that indicates some text recognition occurred.
But there's nothing to demonstrate that this is fundamentally any
different from other OCR packages.
Am I missing something?
> Here is a good link it is an article by Linda Hayes,
> entitled "An Ingenious Solution" If the link changes the
> article can be found using the following keyword search in
> google: [ingenious solution linda hayes]
>
> http://www.stickyminds.com/sitewide...ObjectType=C...
> This article extensively discusses this problem as it
> directly relates to automated testing.
Peter, I'm not sure this is a good example for you to cite.
The solution in the article involved exposing the internal methods of
the objects under test, so that they can be used by a scripting
language.
As far as I can tell, that's not what you are proposing to do.
| |
| Peter Olcott 2007-11-27, 10:24 pm |
|
"zerble" <joe.strazzere@gmail.com> wrote in message
news:c810f01b-e68e-48fc-a8d7-9a24f0b1fe40@v4g2000hsf.googlegroups.com...
> On Nov 26, 1:31 pm, "Peter Olcott" <NoS...@SeeScreen.com>
> wrote:
>
>
> I see a page that indicates some text recognition
> occurred.
> But there's nothing to demonstrate that this is
> fundamentally any
> different from other OCR packages.
>
> Am I missing something?
Every other OCR system in the world achieved 0% accuracy on
this test sample, my system achieved 100% accuracy.
Conventional stochastic OCR systems are at least twenty-fold
slower. Conventional OCR systems are very poorly suited for
recognizing non text graphic images, thus useless for GUI
Scripting.
>
>
> Peter, I'm not sure this is a good example for you to
> cite.
> The solution in the article involved exposing the internal
> methods of
> the objects under test, so that they can be used by a
> scripting
> language.
>
> As far as I can tell, that's not what you are proposing to
> do.
The reason that I posted this article, was to show the exact
problem that my system solves. My system solves this problem
much more easily, and in many more cases than the solution
provided by this article.
The solution provided in this article only applies if one
has all of the source code, it won't work on custom controls
from third parties.
My solution does not require the security risk of exposing
hooks to system internals. With my system the underlying
application remains the same. The application that is tested
is the same application that the customers receive.
| |
| Michael Bolton 2007-11-27, 10:24 pm |
| > My system should be able to automatically operate most any
> custom GUI control that can be conceived. It could even play
> fast paced video games (that expose nothing of their
> internal state) and win these games. I can foresee no
> aspect of any GUI control that can not be easily
> automatically operated using my technology.
....
> Eventually, I expect my system to require far fewer steps in
> deriving automation test scripts than any other system. Many
> of the details of this have been fully elaborated. The
> current design may have already achieved this, I have not
> yet taken the time to carefully examine every alternative
> system.
And from the Web site: GuiCommander enables these programs to
understand the meaning of what SeeScreen "sees" so that they can
operate the graphical user interface.
However, as Shrini points out:
[color=darkred]
>
re human intelligence and intervention, can not automated with respect to execution.
This is a point to which you didn't respond. Maybe you don't care
about it, which would be reasonable if your interest is in providing
input to and extracting visible output from a screen. That could be
valuable.
However, the eyes and the hands are not the parts that do the
testing. The brain is the part that does the testing. Fast and easy
input and output is nice, but at some point a sapient agent (http://
www.satisfice.com/blog/archives/99) is needed to make decisions about
what the output means. Recognizing a button programmatically is
relatively easy. That is, I know it's sometimes hard, but it's
trivial next to the problems of recognizing whether there's a problem
that might annoy, frustrate, or victimize a user; or deciding what to
do in a confusing situation; or reporting on a problem in a meaningful
way. (This is known as the oracle problem.) In cases where we're
looking for those kinds of things--that is, when we're following an
investigative process, exploring around, making discoveries--I'd
rather have a person configuring, operating, and observing the
application. In cases where we're in a confirmatory mode, lower-level
tests seem to provide higher value at lower cost. Your tool looks
like it might reduce the automation cost at the GUI end, but if the
value is low (because of the oracle problem), it doesn't really matter
how little the automation costs.
---Michael B.
| |
| zerble 2007-11-27, 10:24 pm |
| On Nov 27, 12:10 pm, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
>
>
> Every other OCR system in the world achieved 0% accuracy on
> this test sample, my system achieved 100% accuracy.
> Conventional stochastic OCR systems are at least twenty-fold
> slower.
An interesting claim.
Even assuming you tried this test sample with every other OCR system
in the world, it's a rather odd sample to use. The font and size are
certainly not typical of applications that I've tested.
100% accuracy on one vendor-chosen test sample doesn't tell us very
much.
A working executable that we could use to check the recognition
accuracy on our own samples would tell us far more.
> Conventional OCR systems are very poorly suited for
> recognizing non text graphic images, thus useless for GUI
> Scripting.
But that's not really the question at hand.
Your test sample was not "non text graphic images".
And nobody would bother to try and use OCR for recognizing non text
graphic images anyway. Instead, they would use other image comparison
methods.
> The reason that I posted this article, was to show the exact
> problem that my system solves. My system solves this problem
> much more easily, and in many more cases than the solution
> provided by this article.
I guess I'm not sure what problem you are really solving, then.
If you are only trying to "recognize" visible objects graphically,
then Ok - perhaps you have an interesting method.
But of course automated testing is much more than simply finding a
particular object. That's why the article indicated that they exposed
the internal methods of the objects.
For instance, would your recognition system allow the tester to select
the 115th item in a non-standard combobox, for example?
Would your system be able to click a button if the color, shape, and
text changed (but the internal ID remained the same)?
Would your system be able to verify that the read-only state of a non-
standard checkbox-like object was set to True?
> The solution provided in this article only applies if one
> has all of the source code, it won't work on custom controls
> from third parties.
That may be true.
> My solution does not require the security risk of exposing
> hooks to system internals.
I believe the article indicates that the test hooks never go to
customers - thus no security risk.
Peter - you may have a terrific new object recognition method - one
that will be dramatically better than anything existing. It's just
not at all obvious from this discussion, or from your web site.
When you are ready to post a trial version, or lots more details, let
us know. I enjoy evaluating and comparing these sorts of tools, and
would welcome something that was really new and different.
| |
| Peter Olcott 2007-11-27, 10:24 pm |
|
"Michael Bolton" <michael.a.bolton@gmail.com> wrote in
message
news:42db79d8-d165-4374-a7a1-483dd02ab5c8@w28g2000hsf.googlegroups.com...
>
> ...
>
>
> And from the Web site: GuiCommander enables these programs
> to
> understand the meaning of what SeeScreen "sees" so that
> they can
> operate the graphical user interface.
>
> However, as Shrini points out:
>
>
> This is a point to which you didn't respond. Maybe you
> don't care
> about it, which would be reasonable if your interest is in
> providing
> input to and extracting visible output from a screen.
> That could be
> valuable.
>
> However, the eyes and the hands are not the parts that do
> the
> testing. The brain is the part that does the testing.
> Fast and easy
> input and output is nice, but at some point a sapient
> agent (http://
> www.satisfice.com/blog/archives/99) is needed to make
> decisions about
> what the output means. Recognizing a button
> programmatically is
> relatively easy. That is, I know it's sometimes hard, but
> it's
> trivial next to the problems of recognizing whether
> there's a problem
> that might annoy, frustrate, or victimize a user; or
> deciding what to
> do in a confusing situation; or reporting on a problem in
> a meaningful
> way. (This is known as the oracle problem.) In cases
> where we're
> looking for those kinds of things--that is, when we're
> following an
> investigative process, exploring around, making
> discoveries--I'd
> rather have a person configuring, operating, and observing
> the
> application. In cases where we're in a confirmatory mode,
> lower-level
> tests seem to provide higher value at lower cost. Your
> tool looks
> like it might reduce the automation cost at the GUI end,
> but if the
> value is low (because of the oracle problem), it doesn't
> really matter
> how little the automation costs.
>
> ---Michael B.
>
One crucial aspect of automated testing that does not
involve the oracle problem is regression testing. My tool
does not and can not provide a human degree of intelligence.
Currently the only thing that can do that is an actual
human.
What my tool does provide is a system whereby any graphical
user interface can be automatically operated by a single
cohesive system in fewer steps and in many more instances
than any alternative system. This by itself fills an
important niche.
Alternative systems generally must use entirely different
technology to automate web applications than the technology
that they use to automate online applications, desktop
applications, and command line applications. This typically
involves differing user interfaces corresponding to the
differing technologies.
Because my system is based on a single technology it can
provide a single cohesive user interface, thus providing far
less learning curve than alternatives systems.
| |
| Peter Olcott 2007-11-27, 10:24 pm |
|
"zerble" <joe.strazzere@gmail.com> wrote in message
news:95efe07b-6281-43b2-97f6-31fe3bdeedd3@r60g2000hsc.googlegroups.com...
> On Nov 27, 12:10 pm, "Peter Olcott" <NoS...@SeeScreen.com>
> wrote:
>
>
> An interesting claim.
>
> Even assuming you tried this test sample with every other
> OCR system
> in the world, it's a rather odd sample to use. The font
> and size are
> certainly not typical of applications that I've tested.
I tested this sample against OmniPage 15, ABBYY, and
Kleptomania. The first two are stochastic based recognizers
and can not function with fewer than 300 DPI. It became
apparent that no stochastic system could function at display
screen resolutions of 96 DPI.
The latter system is not stochastic yet can not function
with font smoothing, and had major accuracy issues with
other text samples that it could recognize. This was the
only system that could operate at display screen
resolutions.
>
> 100% accuracy on one vendor-chosen test sample doesn't
> tell us very
> much.
>
> A working executable that we could use to check the
> recognition
> accuracy on our own samples would tell us far more.
>
I can't release my working prototype just yet. I can say
that my system has been thoroughly tested against many
different FontInstances, and in these exhaustive tests
(every possible combination of three characters) the only
failures were in cases where the FontInstance itself was
inherently ambiguous.
Some FontInstances such as Arial, have different characters
with identical character glyphs and between glyph spacing.
Arial 8-Point, NonBold, NonItalic, NonUnderlined forms the
glyphs for UpperCase(i) and LowerCase(L) using identical
images. The typical rules of English combined with a
dictionary could disambiguate this, or an unambiguous
FontInstance such as Tahoma could be selected.
>
> But that's not really the question at hand.
> Your test sample was not "non text graphic images".
>
> And nobody would bother to try and use OCR for recognizing
> non text
> graphic images anyway. Instead, they would use other
> image comparison
> methods.
In order to automatically operate graphical user interface
controls on the basis of their display screen pixels, many
non text elements must be recognized.
>
>
> I guess I'm not sure what problem you are really solving,
> then.
The problem elaborated in the first paragraph of this
article:
http://www.stickyminds.com:80/sitew...L&ObjectId=6408
>
> If you are only trying to "recognize" visible objects
> graphically,
> then Ok - perhaps you have an interesting method.
>
> But of course automated testing is much more than simply
> finding a
> particular object. That's why the article indicated that
> they exposed
> the internal methods of the objects.
>
> For instance, would your recognition system allow the
> tester to select
> the 115th item in a non-standard combobox, for example?
Certainty, it would make more sense to have it match a
particular item, in this way the test would not break if
items are added or removed.
>
> Would your system be able to click a button if the color,
> shape, and
> text changed (but the internal ID remained the same)?
Within a reasonably small finite set of changes, yes, unless
the changes could be predicted by reading configuration
information, in this case an infinite number of changes
could be accommodated. The system could easily handle
thousands of possible alternatives for a single GUI control.
>
> Would your system be able to verify that the read-only
> state of a non-
> standard checkbox-like object was set to True?
Easily. The SeeScreen system can simultaneously search the
display screen for about one million different graphical
objects. This limitation is only based on current memory
prices, thus will increase beyond one million as more memory
becomes available for lower prices.
>
>
> That may be true.
>
>
> I believe the article indicates that the test hooks never
> go to
> customers - thus no security risk.
The DLL that interfaces with the hooks never goes to the
customers, yet the actual hooks are still in place. This is
discussed in the first reader comment on this article. You
must click the "Read On" link at the end of the article to
see the whole article.
>
> Peter - you may have a terrific new object recognition
> method - one
> that will be dramatically better than anything existing.
> It's just
> not at all obvious from this discussion, or from your web
> site.
>
> When you are ready to post a trial version, or lots more
> details, let
> us know. I enjoy evaluating and comparing these sorts of
> tools, and
> would welcome something that was really new and different.
I will provide as many details as I can to answer any
questions regarding the capability of this system.
| |
| zerble 2007-11-27, 10:24 pm |
| On Nov 27, 2:50 pm, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
>
> Certainty, it would make more sense to have it match a
> particular item, in this way the test would not break if
> items are added or removed.
Not necessarily.
It would make sense if you are simply trying to select an item labeled
"xxx" no matter where in the cobobox it appears.
But if you are trying to select the nth item in the list, you may not
be able to depend on the text of that item.
For example:
Test Case: "Select the 8th-ranked chess player from the list"
>
> Within a reasonably small finite set of changes, yes, unless
> the changes could be predicted by reading configuration
> information, in this case an infinite number of changes
> could be accommodated. The system could easily handle
> thousands of possible alternatives for a single GUI control.
This is why many tools can access objects using non-GUI attriibutes,
like an ID.
The tester just wants to submit a page, for example.
In one build of the software there is a blue button labeled "Go".
In the next build, it is a Green non-standard image labeled "Submit".
These are the kinds of problems test automators face every day.
>
> Easily. The SeeScreen system can simultaneously search the
> display screen for about one million different graphical
> objects. This limitation is only based on current memory
> prices, thus will increase beyond one million as more memory
> becomes available for lower prices.
I think you are missing the point.
The read-only state of an object is not always a visible property.
It's not a question of how many graphical objects you can search for.
Some properties simply don't make themselves visible.
>
>
> The DLL that interfaces with the hooks never goes to the
> customers, yet the actual hooks are still in place. This is
> discussed in the first reader comment on this article. You
> must click the "Read On" link at the end of the article to
> see the whole article.
It seems to say:
"In other words, the application software does not have to be
recompiled because the test hook is not embedded within it."
> I will provide as many details as I can to answer any
> questions regarding the capability of this system.
Thanks, but I'm afraid these written details don't seem to be telling
us much.
You are clearly focusing on image recognition as the key, defining
feature. But that by itself doesn't make for much of a test
automation solution, in my opinion.
There may be something useful here, or there may not. It might be
real, or might be vaporware. Perhaps when your working prototype is
ready for public use we'll be able to tell one way or the other.
Good luck, Peter! Let us know how this works out.
| |
| Peter Olcott 2007-11-27, 10:24 pm |
|
"zerble" <joe.strazzere@gmail.com> wrote in message
news:3f01386e-adac-41b2-a2d5-a3eb7ca27a82@e6g2000prf.googlegroups.com...
> On Nov 27, 2:50 pm, "Peter Olcott" <NoS...@SeeScreen.com>
> wrote:
>
>
> Not necessarily.
> It would make sense if you are simply trying to select an
> item labeled
> "xxx" no matter where in the cobobox it appears.
>
> But if you are trying to select the nth item in the list,
> you may not
> be able to depend on the text of that item.
That would be very easy to do with my system.
>
> For example:
> Test Case: "Select the 8th-ranked chess player from the
> list"
>
>
> This is why many tools can access objects using non-GUI
> attriibutes,
> like an ID.
>
> The tester just wants to submit a page, for example.
> In one build of the software there is a blue button
> labeled "Go".
> In the next build, it is a Green non-standard image
> labeled "Submit".
>
> These are the kinds of problems test automators face every
> day.
The key benefit of my system is that it works even when no
aspect of the internal state is exposed, and thus no
alternative automation tool can function. Probably the best
use of my system might be if its capability was embedded
within other automated testing systems, closing the gaps in
what these systems can automate.
>
>
> I think you are missing the point.
> The read-only state of an object is not always a visible
> property.
You said the read-only state of a non-standard checkbox. It
would seem that a checkbox would be required to have a
visible state or it would not meet the specification of a
checkbox.
>
> It's not a question of how many graphical objects you can
> search for.
> Some properties simply don't make themselves visible.
These properties are derived using other means.
>
>
> It seems to say:
> "In other words, the application software does not have to
> be
> recompiled because the test hook is not embedded within
> it."
>
Here is a cut-and-paste direct quote:
The security issue is still here. You removed the DLL - who
prevents a potential hacker from writing his own and placing
it exactly where the test one was? As long as the app has
backdoors security will be compromised
>
> Thanks, but I'm afraid these written details don't seem to
> be telling
> us much.
>
> You are clearly focusing on image recognition as the key,
> defining
> feature. But that by itself doesn't make for much of a
> test
> automation solution, in my opinion.
>
Maybe its best use would be as an embedded component of
testing solutions based on other technology. It can
automatically operate the graphical user interface where all
other technologies fail, perhaps these other systems could
use my technology as a component part of their own.
> There may be something useful here, or there may not. It
> might be
> real, or might be vaporware. Perhaps when your working
> prototype is
> ready for public use we'll be able to tell one way or the
> other.
>
> Good luck, Peter! Let us know how this works out.
| |
| zerble 2007-11-27, 10:24 pm |
| On Nov 27, 6:24 pm, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
> Probably the best
> use of my system might be if its capability was embedded
> within other automated testing systems, closing the gaps in
> what these systems can automate.
That would be my suggestion, as you don't really appear to be
approaching a complete test automation system yourself.
> You said the read-only state of a non-standard checkbox. It
> would seem that a checkbox would be required to have a
> visible state or it would not meet the specification of a
> checkbox.
There is no such specification of a non-standard checkbox.
Have a state of read-only or not-read-only does not imply anything
visible.
>
> These properties are derived using other means.
Other means?
>
> Here is a cut-and-paste direct quote:
> The security issue is still here. You removed the DLL - who
> prevents a potential hacker from writing his own and placing
> it exactly where the test one was? As long as the app has
> backdoors security will be compromised
???
Perhaps we are looking at two different things.
When I look at http://www.stickyminds.com/sitewide...L&ObjectId=6408
I don't find what you are quoting.
> Maybe its best use would be as an embedded component of
> testing solutions based on other technology.
Perhaps you are correct in that.
| |
| Peter Olcott 2007-11-28, 4:39 am |
|
"zerble" <joe.strazzere@gmail.com> wrote in message
news:590a1c81-71be-4b4f-84a7-f2b46d7fcc93@d21g2000prf.googlegroups.com...
> On Nov 27, 6:24 pm, "Peter Olcott" <NoS...@SeeScreen.com>
> wrote:
>
>
> That would be my suggestion, as you don't really appear to
> be
> approaching a complete test automation system yourself.
>
>
> There is no such specification of a non-standard checkbox.
> Have a state of read-only or not-read-only does not imply
> anything
> visible.
If it is not visible then how can it be called a checkbox?,
there has to be a box and there has to be a check, or it is
not even a non standard checkbox.
>
>
> Other means?
There are many properties that are not typically visible
unless and until one clicks through a sequence of menus or
such like. For example the default font for the user
interface is not visible unless one first opens the Display
Properties DialogBox, and then proceeds with several other
steps in a defined sequence.
>
>
> ???
> Perhaps we are looking at two different things.
> When I look at
> http://www.stickyminds.com/sitewide...L&ObjectId=6408
> I don't find what you are quoting.
It is included as the first member comment (by Alexander
Nekrasov 5/20/2003) after the end of the article, and then
you must also click on the "Read On" link at the end of this
first comment, to unhide the rest of this comment.
>
>
> Perhaps you are correct in that.
| |
| zerble 2007-11-28, 8:18 am |
| On Nov 27, 11:54 pm, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
>
> If it is not visible then how can it be called a checkbox?,
> there has to be a box and there has to be a check, or it is
> not even a non standard checkbox.
(sigh)
Ok, then. If it would make things clearer, call it a "non-standard
fubar".
The point is that some attributes of GUI objects are simply not
visible.
Just looking at it with your eyes (or with a piece of code designed to
mimic your eyes), cannot expose everything that might be of interest
to a tester.
>
>
>
> There are many properties that are not typically visible
> unless and until one clicks through a sequence of menus or
> such like. For example the default font for the user
> interface is not visible unless one first opens the Display
> Properties DialogBox, and then proceeds with several other
> steps in a defined sequence.
Again, in some simple cases, clever clicking might expose something
useful.
But, clearly some properties will never be visible.
Better, faster image recognition might be a useful addition to a test
automation suite.
But by itself it won't be sufficient to replace a full-featured test
automation system.
You seem to have a solution in search of a problem here.
You've got a concept that you are thinking about productizing. Good.
In my opinion, you should think about trying to license it to an
existing automated test tool vendor, rather than trying to convince
yourself that it could replace them. To me, that's a waste of time.
I'm not trying to be overly critical here Peter, but it doesn't sem to
me that you understand test automation well enough to come up with a
viable commercial test tool.
| |
| Peter Olcott 2007-11-28, 7:23 pm |
|
"zerble" <joe.strazzere@gmail.com> wrote in message
news:31ba1144-05ba-4e2d-baf7-471e7f5a41af@e67g2000hsc.googlegroups.com...
> On Nov 27, 11:54 pm, "Peter Olcott" <NoS...@SeeScreen.com>
> wrote:
>
> (sigh)
> Ok, then. If it would make things clearer, call it a
> "non-standard
> fubar".
>
> The point is that some attributes of GUI objects are
> simply not
> visible.
> Just looking at it with your eyes (or with a piece of code
> designed to
> mimic your eyes), cannot expose everything that might be
> of interest
> to a tester.
When a PhD computer scientist critiqued my system and
derived specific examples of this I was able to derive ways
to circumvent each and every one of these limitations. In
each of these cases there was an aspect that could be made
visible using the same means that would be required for a
human operator to interact with the GUI control in question.
>
>
> Again, in some simple cases, clever clicking might expose
> something
> useful.
> But, clearly some properties will never be visible.
If they can not be made visible by any means, then a human
operator would also have difficulty with such a custom
control. In each case where a specific example of this was
provided, the solution that emerged was based on what a
human operator would do.
>
> Better, faster image recognition might be a useful
> addition to a test
> automation suite.
> But by itself it won't be sufficient to replace a
> full-featured test
> automation system.
>
> You seem to have a solution in search of a problem here.
>
> You've got a concept that you are thinking about
> productizing. Good.
> In my opinion, you should think about trying to license it
> to an
> existing automated test tool vendor, rather than trying to
> convince
> yourself that it could replace them. To me, that's a
> waste of time.
>
> I'm not trying to be overly critical here Peter, but it
> doesn't sem to
> me that you understand test automation well enough to come
> up with a
> viable commercial test tool.
It would probably be better as a plug-in to existing
commercial tools. Since the interfaces are based on ActiveX,
this system could easily plug into any existing system.
The key benefit of my technology is that is that it
automatically operates aspects of the graphical user
interface in cases where no other tool will function. The
basic system apart from GUI testing will also allow very
powerful GUI Scripts that take very little development time.
These scripts can be written using most any programming
language, including all of the new .NET languages.
| |
| zerble 2007-11-28, 7:23 pm |
| On Nov 28, 10:05 am, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
>
> If they can not be made visible by any means, then a human
> operator would also have difficulty with such a custom
> control. In each case where a specific example of this was
> provided, the solution that emerged was based on what a
> human operator would do.
Again, I think you are missing the point.
You can always make invisible properties "visible" by changing the
underlying code in the GUI. For example you could cause the object to
write its invisible properties into a log file when you hover over the
GUI object. But, I'm guessing that's not what most people would want
to do.
Human users of GUIs don't know, nor care about the non-visible parts -
except if they are trying to test the application. Then they might
care. A lot.
Here's an exercise:
- go to the Google home page (www.google.com)
- point your tool at the large Google image
- what attributes can you see?
Using the IE Developer's Toolbar, I can see:
- the ALT text is "Google"
- the height is 110
- the width is 276
- the src is http://www.google.com/intl/images/logo.gif
- it is center-aligned
etc
These may not be visible to a normal human operator, but may be
critical to a tester.
> It would probably be better as a plug-in to existing
> commercial tools.
I agree.
>Since the interfaces are based on ActiveX,
> this system could easily plug into any existing system.
Any system that supports ActiveX, right?
> The key benefit of my technology is that is that it
> automatically operates aspects of the graphical user
> interface in cases where no other tool will function.
I hear what you are saying, but I've yet to see that demonstrated.
> The
> basic system apart from GUI testing will also allow very
> powerful GUI Scripts that take very little development time.
Very powerful, plus very little development time is what all test tool
vendors say.
You haven't demonstrated anything to indicate how you would make more
powerful scripts, nor how you would reduce the development time.
| |
| Peter Olcott 2007-11-28, 7:23 pm |
|
"zerble" <joe.strazzere@gmail.com> wrote in message
news:308ed7c2-b32d-4cf0-b0fb-9d5e9e15a973@s8g2000prg.googlegroups.com...
> On Nov 28, 10:05 am, "Peter Olcott" <NoS...@SeeScreen.com>
> wrote:
>
>
> Again, I think you are missing the point.
>
> You can always make invisible properties "visible" by
> changing the
> underlying code in the GUI. For example you could cause
> the object to
> write its invisible properties into a log file when you
> hover over the
> GUI object. But, I'm guessing that's not what most people
> would want
> to do.
>
> Human users of GUIs don't know, nor care about the
> non-visible parts -
> except if they are trying to test the application. Then
> they might
> care. A lot.
>
> Here's an exercise:
> - go to the Google home page (www.google.com)
> - point your tool at the large Google image
> - what attributes can you see?
>
> Using the IE Developer's Toolbar, I can see:
> - the ALT text is "Google"
> - the height is 110
> - the width is 276
> - the src is http://www.google.com/intl/images/logo.gif
> - it is center-aligned
> etc
>
> These may not be visible to a normal human operator, but
> may be
> critical to a tester.
>
>
> I agree.
>
>
> Any system that supports ActiveX, right?
The system itself does not need to support ActiveX, as long
as the language that the system is written in either
supports ActiveX (all the Microsoft languages, including
..NET) or has third party support provided, as in the case of
Java.
>
>
> I hear what you are saying, but I've yet to see that
> demonstrated.
I would think that the design details that I provided should
have made that apparent.
If a system can "see" graphical user interface controls on
the basis of their pixels in a way similar to the way that
OCR works (this part should be apparent, if not please tell
me what is not clear) and this system "understands" how to
operate these controls (I can't elaborate the details of
this just yet), then it should be obvious that such a system
could operate most any GUI Control that a human operator
could operate. This would necessarily include controls that
do not provide any programmatic interface, as well as
controls that do provide a programmatic interface.
If the part about it "understanding" how to operate the
controls is a given, then is it clear how it works besides
this aspect?
>
>
> Very powerful, plus very little development time is what
> all test tool
> vendors say.
>
> You haven't demonstrated anything to indicate how you
> would make more
> powerful scripts, nor how you would reduce the development
> time.
Let's focus on the first part about more powerful scripts
since I can probably provide this explanation without
divulging any details about my second invention. The second
part can not be elaborated without divulging aspects of my
second invention so this will have to wait for a while.
| |
| zerble 2007-11-29, 8:19 am |
| On Nov 28, 6:35 pm, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
>
>
> I would think that the design details that I provided should
> have made that apparent.
You haven't provided any design details, let alone sufficient design
details to support the conclusion that you could operate GUIs in cases
where no other tool can.
You have made claims of better recognition, and as an example have
displayed a single image with an unusual font you say cannot be
recognized by other OCR systems.
What you haven't done is provided a demonstration where your system
actually operates anything.
> If a system can "see" graphical user interface controls on
> the basis of their pixels in a way similar to the way that
> OCR works (this part should be apparent, if not please tell
> me what is not clear) and this system "understands" how to
> operate these controls (I can't elaborate the details of
> this just yet), then it should be obvious that such a system
> could operate most any GUI Control that a human operator
> could operate. This would necessarily include controls that
> do not provide any programmatic interface, as well as
> controls that do provide a programmatic interface.
>
> If the part about it "understanding" how to operate the
> controls is a given, then is it clear how it works besides
> this aspect?
Even if it is a given that your system can "find" a GUI element (which
you haven't yet demonstrated), it's not at all a given that your
system can "understand" anything at all about the objects it can find.
If you could somehow intuit how a GUI object operates solely based on
the visual appearance, then your system would certainly be super-
human.
>
>
>
> Let's focus on the first part about more powerful scripts
> since I can probably provide this explanation without
> divulging any details about my second invention. The second
> part can not be elaborated without divulging aspects of my
> second invention so this will have to wait for a while.
Sure.
Pick your favorite programming language, or invent a pseudo-langugage
if you must.
Post a code snippet showing how that language would be used to
automate a test without having benefit of your system.
Then post the same code snippet modified to take advantage of your
system.
I would imagine you could do this without divulging details about
either of your inventions, right?
And then we can judge how much more powerful it has become.
| |
| Peter Olcott 2007-11-29, 7:23 pm |
|
"zerble" <joe.strazzere@gmail.com> wrote in message
news:4826fdaa-9885-4c95-968b-3ebf5dfb8673@e10g2000prf.googlegroups.com...
> On Nov 28, 6:35 pm, "Peter Olcott" <NoS...@SeeScreen.com>
> wrote:
>
>
> You haven't provided any design details, let alone
> sufficient design
> details to support the conclusion that you could operate
> GUIs in cases
> where no other tool can.
>
> You have made claims of better recognition, and as an
> example have
> displayed a single image with an unusual font you say
> cannot be
> recognized by other OCR systems.
>
> What you haven't done is provided a demonstration where
> your system
> actually operates anything.
>
Although I have not provided an example of my system
operating anything isn't it obvious that a system that can
"see" the GUI controls on the screen could operate these
controls on the basis of what it "sees" ? I already
provided a concrete example of such a system, Redstone
Software's EggPlant.
http://www.redstonesoftware.com/
http://www.redstonesoftware.com/docs/manuals/index.html
http://www.redstonesoftware.com/doc...ials/index.html
Isn't it also obvious that such a system could operate GUI
controls in the cases where these controls do not
programmatically expose their state, since it does not
depend upon a control programmatically exposing its state?
It is also common knowledge that some GUI controls do not
expose their state.
http://www.stickyminds.com/sitewide...L&ObjectId=6408
>
> Even if it is a given that your system can "find" a GUI
> element (which
> you haven't yet demonstrated), it's not at all a given
> that your
> system can "understand" anything at all about the objects
> it can find.
>
> If you could somehow intuit how a GUI object operates
> solely based on
> the visual appearance, then your system would certainly be
> super-
> human.
>
There is no intuition involved.
>
> Sure.
>
> Pick your favorite programming language, or invent a
> pseudo-langugage
> if you must.
> Post a code snippet showing how that language would be
> used to
> automate a test without having benefit of your system.
> Then post the same code snippet modified to take advantage
> of your
> system.
>
> I would imagine you could do this without divulging
> details about
> either of your inventions, right?
>
> And then we can judge how much more powerful it has
> become.
No those are details that I can not specify because the
patent is not yet filed.
I think that I have proven at least half of my points above.
The one aspect that I can not yet prove is exactly how much
better my solution is than the solution provided by the
Redstone Software, Eggplant technology. Although I can't yet
prove these points here they are:
(1) My system can automatically operate graphical user
interfaces in at least 500% fewer specified programming
steps. The proof of this will have to wait. A substantial
portion of this benefit is directly derived from the fact
that my system can simultaneously search for at least one
million different graphical objects, and the Redstone
Software Eggplant system is limited to searching for one
graphical object at a time.
(2) Because my system is based on a deterministic finite
automaton capable of searching for at least a million
different graphical objects simultaneously, (when searching
for text this limit is much larger) and the Redstone
Software Eggplant technology can only search for one
graphical object at a time my system can automatically
operate graphical user interfaces in cases with rapidly
changing display screen data, where the Eggplant technology
fails to respond quickly enough.
(3) Because the Redstone Software Eggplant system can only
search for one graphical object at a time, it is entirely
incapable of recognizing any text from display screen
pixels. This limitation makes some operations much more
cumbersome.
| |
| zerble 2007-11-29, 7:23 pm |
| On Nov 29, 9:25 am, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
I give up, Peter. There doesn't seem to be any point in continuing
this discussion.
As a professional in the Software Quality Assurance field with a lot
of experience in test automation, I'm always very interested in new
approaches and new technologies.
You are talking about some new recognition technology which I'm sure
is academically interesting.
But, I can't tell if it has any practical commercial application that
makes it superior to what I use every day, or what others use. You
believe it is, but I'm not so sure, and I don't think further
discussion could lead to such a conclusion.
I would be very interested in seeing your system when you actually
have something that can be checked out on an application-under-test.
It doesn't have to be a full-blown test system, but it would have to
be something I could try myself. Without that, it's just interesting
talk, and not much more than vaporware
I will happily offer to be a tester for such a tool in whatever state
you could deliver it. I would be happy to sign an NDA if needed.
Best of luck.
| |
| Peter Olcott 2007-11-29, 7:23 pm |
|
"zerble" <joe.strazzere@gmail.com> wrote in message
news:3a0152f7-0b6a-4cbf-bb4e-4f6376a8482a@i29g2000prf.googlegroups.com...
> On Nov 29, 9:25 am, "Peter Olcott" <NoS...@SeeScreen.com>
> wrote:
>
> I give up, Peter. There doesn't seem to be any point in
> continuing
> this discussion.
>
> As a professional in the Software Quality Assurance field
> with a lot
> of experience in test automation, I'm always very
> interested in new
> approaches and new technologies.
>
> You are talking about some new recognition technology
> which I'm sure
> is academically interesting.
>
> But, I can't tell if it has any practical commercial
> application that
> makes it superior to what I use every day, or what others
> use. You
> believe it is, but I'm not so sure, and I don't think
> further
> discussion could lead to such a conclusion.
>
> I would be very interested in seeing your system when you
> actually
> have something that can be checked out on an
> application-under-test.
> It doesn't have to be a full-blown test system, but it
> would have to
> be something I could try myself. Without that, it's just
> interesting
> talk, and not much more than vaporware
>
> I will happily offer to be a tester for such a tool in
> whatever state
> you could deliver it. I would be happy to sign an NDA if
> needed.
>
> Best of luck.
Thanks for all of your great feedback. I will post again to
this group after I have filed my patent and can describe in
much greater detail the exact user interface to my system.
| |
|
|
|
|
|
|
|