GUI Schmooey

I answered a few questions this week about automating GUI tests. One question was about recommendations for GUI automation tools for non-coders, and the other was about how much time to spend on the GUI in an MVC (model-view-controller) application.

The answers were easy. In the first case, I said that they weren’t going to get ROI from the effort, and they should just test the GUI manually. In the second case, I suggested that they do all of the automation ignoring the view/GUI, and test the GUI manually.

I could expand an entire post on why I gave those answers, but it doesn’t matter. I’m going to go out on a limb and make the following statement.

For 95% of all software applications, automating the GUI is a waste of time.

For the record, I typed 99% above first, then chickened out. I may change my mind again. The point is that I think testers, in general, spend too much time trying to automate GUIs. I’m not against automation – just write automation starting at a level below(*) the GUI and move down from there. I’m not saying that you shouldn’t test the GUI at all – I just don’t see why you wouldn’t want to test it manually, and get people knowledgeable in user experience to help. I just think that in most cases we are wasting our time when we try to automate GUIs, and wonder if anyone has the guts to stop.

 

* What I beam by a “level below the GUI” is automation that works with IAccessible or an object model rather than interacting with UI elements directly.

Similar Posts

  • Who are you?

    I’ve been thinking about how professional testers describe themselves. We have high level labels like Tester, SDET, or Quality Engineer, but beyond those (mostly meaningless) titles, many of us have our own personal missions or visions – the words we want people to associate with us. For example, my twitter bio is, “Long time software…

  • Five for Friday – February 8, 2019

    This FfF is slightly later in the day than normal due to the Seattle snow-pocalypse. I drove my daughter home from an appointment this afternoon. It was snowing, the roads were mostly wet, but it took almost 3 hours to drive twelve miles mostly because people were being stupid. Please, Seattle area readers, read this Now…

  • Five for Friday – Friday, September 28

    Here are a few of the things I found interesting this week. I thought this article about “hacking” British Airways was sort of interesting – but mainly that they glossed over the real hack – “It is likely that the hackers had access to the BA.com site, and modified the code to insert a backdoor.” Read…

  • “Why the UI?”

    Readers of my blog know my stance on UI automation. But, as I’ve forgotten my StickyMinds password, and the answer is longer than 140 characters, so I’m responding here. This article from Justin Rohrman talks about the coolness of Selenium for UI testing. In a paragraph called, “Why the UI”, Justin wrote: The API and…

  • It’s a Beautiful Day

    I may have mentioned this on the old blog, but I’m pretty sure I haven’t mentioned it here yet. O’Reilly media recently released Beautiful Testing – a collection of essays from a variety of testing professionals (including yours truly). I received my copy over the weekend (much to the annoyance, I’m sure, of several other…

5 Comments

  1. YES!!! I tried this (GUI automation) with enthusiasm twice and both times it was too expensive to maintain and nearly impossible to get rid of the false errors. Automation which costs more to create, run, and maintain than the same test run manually is a bad investment and it isn’t recouped if the tests have to be maintained and rewritten ever version. This doesn’t even account for the terrible job of validation that GUI test tools are doing.

    In practice I say 99% although in theory I could agree with 95% with the hope that better ways to validate are possibly on the way along with better tools? Snapshots, screen captures, and “pixel diffing” sucks so bad. We need tools that validate WAY better.

  2. I don’t lump object model and accessibility interfaces together. I see object model as below the GUI. Accessibility interfaces are testing through the GUI – there is a one to one correspondence with elements in the user interface. For disabled people, it IS the user interface.

  3. But how about test automation for stability purposes. Say I have a scenario where I test a set of functions 10000 times in order to find meomry leaks, file system issues or UI freezes?
    Wouldn’t scripted test cases suffice? I mean the ROI is there.
    Of course you could argue that simulating the same actions on low level APIs would do the work faster. But again, that would not be the same as a user would interact with the system.

    Oh, just realized this blogpost is really old…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.