Setting up a Quality Team within KDE

[Anne-Marie Mahfouf]

On 04/08/2012 07:11 AM, Percy Camilo Triveño Aucahuasi wrote:
> Hi Anne, hi all
>
> On Fri, Apr 6, 2012 at 12:03 PM, Anne-Marie Mahfouf
> >This is addressed for 4.9 as "putting in place a few
> >selected areas of functional testing" and hopefully
> >we will assess some automated UI testing tools
> >and start using them in the following releases.
> >I hope we can gather enough beta testers and
> >make this working.
>
> 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?

Thanks for your input,

Anne-Marie
>
> On Fri, Apr 6, 2012 at 12:03 PM, Anne-Marie Mahfouf 
> <annemarie.mahfouf at free.fr <mailto:annemarie.mahfouf at free.fr>> wrote:
>
>     On 04/06/2012 02:23 PM, Aleix Pol wrote:
>
>         On Thu, Apr 5, 2012 at 1:42 PM, Anne-Marie Mahfouf
>         <annemarie.mahfouf at free.fr <mailto:annemarie.mahfouf at free.fr>>
>          wrote:
>
>             Hi,
>
>             We would like to setup a Quality Testing Team within KDE
>             in order to better
>             test our next KDE SC and make the beta process more efficient.
>             Attached is the first draft of the ideas I brainstormed.
>             Source .odt of this
>             document is available at
>             http://quickgit.kde.org/index.php?p=scratch%2Fannma%2Fquality-testing-doc.git
>
>             (We can make it a public Google doc if it is more
>             convenient or an
>             etherpad).
>
>             The document roughly describes 2 areas of action:
>             - reinforcement (labelled "Reinforce") of existing
>             structures (mainly
>             targetted to developers and mainly relevant before the
>             beta stage of the
>             release). This could
>
>             be used as guidelines for new developers. Of course it
>             won't be newbies
>             which will develop Unit Tests or check the code quality.
>             But some guidelines
>             can
>             be useful for libs outside Frameworks.
>             An area of relevant reinforcement that can be currently
>             done is the Review
>             process for new integration.
>             - new infra-structures: this is labelled "New" in the doc:
>             this is what I
>             would see to happen for the 4.9 release.
>
>
>             A new mailing list has been set up in order to discuss all
>             this: please
>             subscribe to it if you would like to be part of this
>             https://mail.kde.org/mailman/listinfo/kde-testing
>             An IRC channel also was created on Freenode:
>             #kde-quality
>
>             Please join the mailing list and the IRC channel so we can
>             setup a plan to
>             start putting all this in gear!
>
>             Thanks in advance,
>
>             Anne-Marie and Myriam
>
>         Hi!
>         I think this project is a very interesting idea and definitely
>         something we need. Said that, I'd like to propose some small
>         changes
>         on how this should be done.
>
>         In the document there are some actions to be taken that sound
>         a bit
>         too technical, for example it specifies reinforcing the unit
>         testing.
>         This is something that we should have been doing already and I
>         don't
>         see someone from the Quality Team going to a development team and
>         improving that.
>
>     Making unit tests is the developer task (and the document mentions
>     it) and we do have solit Unit Tests in kdelibs and Frameworks and
>     kdepimlibs. However there are other libs within KDE where maybe
>     unit tests are not as present as they should (I did not research
>     that though). Also, about unit tests, it's not only writing them,
>     it's also running them. This is not done in a regular basis and
>     needs to be automated in the future and the fails need to be fixed.
>     No newbie will ever touch to any Unit Tests of course. And any
>     action will be discussed with the gurus in this field (/me does
>     not point to David).
>
>     We have many tools for developers which are not fully used: latest
>     great tool is Jenkins which I was aware of only recently. My label
>     "Reinforce" is to take full advantage of those existing tools.
>
>     (It would be cool if at Akademy there are some talks focusing on
>     using these tools.)
>
>
>         What I'd like to see is this new team testing KDE and its
>         applications
>         from a user perspective, specifying the different perspectives
>         the KDE
>         end user will face (different OS, different form factors, etc) and
>         reporting problems (not necessarily bugs, as in crashes) and
>         proposing
>         new solutions.
>
>     This is addressed for 4.9 as "putting in place a few selected
>     areas of functional testing" and hopefully we will assess some
>     automated UI testing tools and start using them in the following
>     releases. I hope we can gather enough beta testers and make this
>     working.
>
>         I'm really hopeful about such a team, I think it's a good
>         opportunity
>         for KDE to be able to reach contributions for a less common
>         sector of
>         our community and keep working together for a greater KDE
>         experience.
>
>         Cheers!
>         Aleix
>
>     Thanks for your input!
>
>     Anne-Marie
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120408/bb28b06f/attachment.htm>