I would be interested in participating as "dumb user", <div><br></div><div>The 'black box' sounds interesting and a way to organize dumb users for debugging/edu/user docs/ergonomics</div><div><br></div><div>
mars<br><br><div class="gmail_quote">On Wed, Jun 8, 2011 at 11:13 AM, MALIK Julien <span dir="ltr"><<a href="mailto:julien.malik@c-s.fr">julien.malik@c-s.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello,<br>
<br>
Do you know about Sikuli ?<br>
<a href="http://sikuli.org/" target="_blank">http://sikuli.org/</a><br>
<br>
I never tested it, but it seems very nice for the "black box" testing, and can probably handle the automatic screenshot generation.<br>
<br>
Cheers,<br>
Julien<div><div></div><div class="h5"><br>
<br>
Quoting Andrew Chapman <<a href="mailto:andrew.chapman@donkagen.co.uk" target="_blank">andrew.chapman@donkagen.co.uk</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think that there are (at least) two different types of testing that are<br>
valuable for a project like QGIS and both play important roles. Different<br>
people use different names, but here's my version...<br>
1) White box: This is very much in the hands of the developer and is aimed<br>
at proving the functionality of their code - stop the bug before it gets out<br>
of your own hands. This type of testing knows how the code should work and<br>
typically, among other things, explores the boundary conditions.<br>
2) Black box: This has no special knowledge of how the internals works and<br>
tests as a dumb user... that can be relied on to provide the same test<br>
coverage every time. One obvious use of this is for regressions testing of<br>
the finished build, but I would suggest that with minor enhancements it<br>
could be used to help ease some of the user documentation tasks.<br>
QGIS supports multiple languages and operating systems, is released<br>
regularly but, consequently, it is hard to produce user manuals and<br>
tutorials with the most appropriate screen shots, etc.<br>
If a "black box" type of test harness were developed that could be "trained"<br>
(e.g. recording keystrokes and mouse commands with a way to edit them) plus<br>
the ability to capture images of screen objects (windows, dialogs, buttons,<br>
icons) and save them to named files, this would present further<br>
opportunities. The same test (script?) could be run on builds for different<br>
operating systems, languages and versions. A standard set of build specific<br>
images would be generated and, assuming standard file names and locations,<br>
could automatically be imported into the various user documents. There would<br>
still need to be some manual text editing, but the labour intensive<br>
screenshot processing would be removed.<br>
This must be a common requirement across projects, has anyone come across<br>
any tools that already exist?<br>
Andrew Chapman<br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br>
<br>
</blockquote>
<br>
<br>
<br></div></div>
----------------------------------------------------------------<br>
This message was sent using IMP, the Internet Messaging Program.<div><div></div><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</div></div></blockquote></div><br></div>