Setting up a Quality Team within KDE

Albert Astals Cid aacid at
Sun Apr 8 16:21:52 BST 2012

El Diumenge, 8 d'abril de 2012, a les 17:13:54, Pau Garcia i Quiles va 
> On Sun, Apr 8, 2012 at 4:03 PM, Anne-Marie Mahfouf <
> annemarie.mahfouf at> wrote:
> > **
> > 
> > 
> > Indeed, Nice idea, I think this is the right focus to (auto)test the
> > functionality/features of the app. I've searched some info about this
> > topic
> > and found this:
> > 
> >
> > 
> > It has full support for KDE/Qt (>4.x) apps and the scripts (for
> > autotesting) can be written with Python.
> > 
> > My 0.5 cents :)
> > 
> > Cheers,
> > Percy
> > 
> > Yes this is maybe the best free tool to do the job. DO you or anybody have
> > used it already?
> Does that tool support QML? Is there an active team behind it?
> Writing UI tests ("functional tests") is a hell of a lot of work and
> choosing the wrong tool means in 2 years we may need to maintain the tool
> ourselves or rewrite all the tests for another tool.
> I can tell you TestComplete's support for Qt is pretty limited. I have not
> tested LDTP because we needed support for Windows and Linux for our Qt
> projects.
> Squish is the best tool we evaluated at work for Qt, it does support Qt
> Quick and there is a company maintaining it (Froglogic, founded by KDE
> developers and employing many KDE developers). A few more arguments
> pro-Squish: it's cross-platform (which means we can run the same tests on
> Linux, Windows, Mac and any other platform we support) and the
> client-server architecture is very useful when testing client-server
> applications, actual environments and/or using virtualization to run the UI
> tests after each daily build.

Did you guys ever try Testability? I've been using lately and works pretty 
well and has the added value of being Free Software.


> Talking about virtualization, what we do at work is we have daily builds
> for master and stabilization branches and we run tests in virtual machines.
> We are currently testing on 12 platforms. We have several "testing
> profiles" (test suites) so that we can quickly say the equivalent of "this
> version of kdelibs is broken, do not bother performing any further testing:
> just flag this build as broken". Everything is automated and launched from
> the continuous integration tool as the build finishes.
> I'm a bit out of the testing stuff at work, and very very busy, but if we
> are serious about it, I can still give some advice and ask some of the
> verification and validation people if they are interested in joining.
> PS: Let's continue the discussion in kde-testing@

More information about the kde-core-devel mailing list