[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Preventing KDE usability bugs/regressions
From:       Ellen Reitmayr <ellen () kde ! org>
Date:       2006-01-23 12:48:32
Message-ID: 200601231348.32534.ellen () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday, 23. January 2006 03:27, Markus wrote:
> On Thursday 15 December 2005 12:50, Ellen Reitmayr wrote:
> > The wiki is only meant as a place to collect ideas what to test. Frerich
> > and some others know about the wiki and successively implement the
> > things as test cases. Others wanting to contribute implementing criteria
> > are highly welcome :)
>
> The fact that these test cases are implemented after initial coding of the
> UI is probably good for those writing the test cases now, but I would like
> to ask how this is to be done for further revisions? In other words, once
> UI testing code has been added to an application and the application
> undergoes the standard evolution process during which code is modified, how
> is the test case integrity maintained? A lazy programmer could just delete
> or comment the precondition checks and thus make the test cases pass every
> time. Not that anyone would do that on purpose, but it might happen. Test
> cases would thus deterioate in quality over time.

Hm, I don't know too much about the technical implications of testing, but in 
the case of Squish testing nothing has to be done in the application code. 
Test cases are defined and specified in a squish config file. Squish then 
goes through the applicaiton and triggers the actions specified there, 
including preconditions. 

As far as I know this approach assumes that internal names or displayed labels 
of input widgets remain the same. Otherwise fine tuning of the test case 
config is required.

> Can anyone who has experience with this tell what a promising approach
> would be, other than manually checking the test cases on every revision ?
>
> > But we should think of a way how to mark what criteria is already
> > implemented, and which not. Status tags? Or any better ideas?
>
> Status tags are probably fine.

-- 

Ellen Reitmayr
KDE Usability Project
usability.kde.org

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


[prev in list] [next in list] [prev in thread] [next in thread]