Setting up a Quality Team within KDE

[Alexander Neundorf]

On Thursday 12 April 2012, Thomas Zander wrote:
> On Thursday 12 April 2012 21.01.53 Alexander Neundorf wrote:
> > We use Squish at work and it works well.
> 
> I've been on many projects and often the project manager thinks they need
> squish, but in the end it just doesn't have any positive impact on the
> product or the quality.
> The most recent project I was on for almost a year had a whole testing team
> and they have tried to get our Qt app to be tested using squish, this is a
> project that followed very specific UI specifications so its a dream to
> have the squish kind of testing for it.
> In the end it was hardly used for mostly technical reasons, and we never
> got to a point where we had a positive report of a regression. And we
> certainly had regressions ;)  The tool just never found them.
> 
> Its not squish itself thats a problem per sé, its the concept of testing
> the way the application looks which is broken by design.  I think it would
> be good to avoid spending resources on this.

Yes, how good squish works for you depends on at least two things:

* how well you set up your squish scripts, object map, etc. If done ad hoc, 
you end up in an unmaintainable mess. If done carefully, it works.

* and of course, what you actually test. We don't really test that dialogs 
etc. still look the same, we use squish to drive our software, see that it 
doesn't crash while doing that, that the expected actions work properly, and 
the produced output data is correct. We actually try to do things directly in 
many cases to stay independent from GUI details, i.e. we call slots and check 
Qt properties directly from the python scripts.

Alex