Fwd: Setting up a Quality Team within KDE

Myriam Schweingruber myriam at kde.org
Wed Apr 11 10:23:45 UTC 2012


---------- Forwarded message ----------
From: Pau Garcia i Quiles <pgquiles at elpauer.org>
Date: 2012/4/8
Subject: Re: Setting up a Quality Team within KDE
To: kde-core-devel at kde.org, kde-testing at kde.org




On Sun, Apr 8, 2012 at 4:03 PM, Anne-Marie Mahfouf
<annemarie.mahfouf at free.fr> 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:
>
> http://ldtp.freedesktop.org/wiki/Home
>
> 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.

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@

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

_______________________________________________
Kde-testing mailing list
Kde-testing at kde.org
https://mail.kde.org/mailman/listinfo/kde-testing



-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)


More information about the Kde-testing mailing list