2018 bis heute | 2017 2016 2015 2014 | 2013 | 2012 | 2011 2010 2009 | 2008 | 2007

(ältere Archiveinträge vor 2007 nicht dargestellt, aber in der Suche enthalten)

Mailingliste - Einträge 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.