Logo QF-Test

Finding valuable answers
in the Mailing List Archive.

 

Free Trial  Download  Buy

Thomas Max, QF-Test training and support

Use the full-text search on our web site to find helpful tips on the mailing list.

Thomas Max, 
Sr. Software Engineer & Trainer, QFS

2016 up to now | 2015 | 2014 | 2013 | 2012 | 2011 | 2010 | 2009 | 2008 | 2007

(older archive entries before 2007 are not shown here, but included in the onsite-search)

Mailing List - Entries of 2007


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[QF-Test] How to use automated GUI tests in a productive way?


  • Subject: [QF-Test] How to use automated GUI tests in a productive way?
  • From: Hans Schwaebli <hans_schwaebli@?.com>
  • Date: Thu, 16 Aug 2007 01:37:05 -0700 (PDT)

I wonder how to handle the redundancy between JUnit and automated GUI tests.
Currently I favor this solution:

- test as much as possible with JUnit tests
- avoid testing with automated GUI tests what has already been tested with JUnit tests
- test GUI specific stuff with automated GUI tests
- test integration of application components with GUI tests
- if bugs, which are not GUI specfic are fixed, the JUnit test has to be updated to include a test for this
- only bug fixings, which are GUI and integration specific need to be tested with automated GUI tests
 
If you write automated GUI tests, these dangerous things can happen:
- developers get no time for writing JUnit tests
- changes are poorly tested by developers
- the responsibility for testing is pushed off to the writer of the automated GUI tests
- developers expect from the writer of the GUI tests that he fixes their bugs which he discovered
- quality declines because quality is delegated to the writer of the automated GUI tests
- the one who informs about bugs is seen as a bearer of bad messages and becomes not liked
- effort for writing GUI tests is underestimated by managers because they see quick and easy examples and expect too fast results because of this
 
Writing automated GUI tests requires a lot of know how and skill. If you don't do it right, you don't win anything compared to manual testing. In a very complicated environment, adding automated GUI tests increases the complexity. You will need at least one person, who specialises in writing GUI tests. And it even could be, that it would be too complicated, to teach the developers to write GUI tests.
 
Often these problems are ignored or if you ask for a solution, people stare at you and shrug their shoulders. Usually none of this is written in a manual, although it is very important to have solutions for this. An unanswered question is: What does introducing automated GUI tests means to project management? What problems can arise and how to handle them? What are the hidden preconditions of using automated GUI tests in a productive way?
This is meant to be an open discussion. I am looking forward to read your comments on this.


Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
Videos Downloads Documentation Buy Free Trial