If it is not a new unexpected confirmation dialog box that shows up, then it may be a unique GUI control identifier that either changed or is even missing. The response could also be slower than originally recorded. That means we have to either extend the script with hard-coded extra wait statements or - if you are smarter - write some extra logic which always waits for the control to load completely before it gets "touched". The object could also be at a different location, let's say in a list that is sorted differently than before. Hope you didn't record the position but negotiated with the developer for a predicable algorithm so your roboter is still able to reach it even though it shows up somewhere else.Poor you if one detects that the developers now use third party controls that your test automation tool can't deal with. You might also experience ugly test script- or module-dependencies. As if this wasn't enough, you may work in a world where testers don't control the test environment where others can change or update configuration without you knowing until you see the script failing. You may also experience a deployment of a new software version in the middle of test execution or while you are playing Sherlock Holmes to investigate a real fat bug. Your script might only work from your workstation but not from the server you're triggering and executing it ...from one day to the other.
And often, even if none of those typical UI test automation challenges is one that you face today, you will still have to sit there watching the script running, so you're ready for some extra test script babysitting actions. If you weren't there observing your scripts but going out for a coffee instead, don't expect your roboter to have completed successfully its job when you've come back to your desk...
That is just a few of the reasons, why I love testing below the UI so much.
This comment has been removed by the author.
ReplyDeleteHI,
ReplyDeleteBig fan of your Cartoons!!!...They are simply awesome.
A Question, How and what do you test on below UI part, if not the GUI functionality?
ThanX for the flowers. Unfortunately has been quite a while since I last published a cartoon. Too much work keeps me away from drawing. With testing below the UI I mean testing on a SOAP WebService layer. If you look at the application-under-test as a stack of layers that starts with the GUI-Layer, followed by a business logic layer and ending with a database access layer, then what I like most is testing between the business layer and the GUI layer. Most of the defects we find in our company are defects deep down either in the architecture of the system or a piece of business logic is wrong. GUI testing makes sense to find defects in the GUI, but it is less effective to find problems in architecture and business layer. We have a system that allows web-users to store data via our User Interface. Other clients may have their own tools which make use of our web service interface (to store objects) instead. Whether an object is created via the UI or via the WebService shall not make any difference in regards to validation and persistance. When I can chose between an automated GUI test and an automated WebService test, then I would go for the latter, because it is more stable, faster to execute and I can add much more variation...and it runs on a daily basis.
Delete