Question

Is there any reason for automating tests that focus on GUI (and not to things under it)? In my opinion GUI (and changes in it) should always be tested by a real person.

What can you gain with the automated GUI focusing tests? My own experience has been that GUI focusing tests almost always break because someone changed something for a really good reason. They seldom seem to find anything interesting.

Answer 1

This is a tough one. Automated testing tools and frameworks do a great job and are well worth the time and effort as long as the GUI does not change too much. The problem with automated testing is that it breaks down precisely when you need it the most: when the GUI is changing rapidly during a development cycle.

As a result, I have settled on a hybrid approach for the projects I lead and manage. I like to use manual testing on areas of the GUI that are changing rapidly during a development cycle. Once things are pretty stable, we do some sort of automated GUI testing (e.g. Selenium for web apps) that we put into the build process to guard against future regression. If at all possible, QA people write the automated tests. Sometimes developers have to pair with QA testers to do this when the automated tool is too code intensive.

This hybrid approach seems to work well as long as we are using good design practices that separate concerns properly so that unit tests can exercise all underlying logic properly. The one thing you must avoid is weaving application logic into the GUI layer.