Web testing services may or may not include UI test automation. Sure any project may gain from several automated UI tests if all is done right. If automated testing is visualized as a pyramid UI will be on top. But it won’t be because they are the best kind of automated tests. It’s just that the top takes less place within the entire pyramid. And so should UI tests. UI automation is quite a challenge and it will take both time and skill to master it, yet once mastered it will be of colossal benefit to the entire project.
No we are getting near HTML 5. It has quite the potential with all the available UI-level functionality. Of course lots has to be tested manually even within HTML 5 apps but that is a topic for a different post.
So how does one automate UI testing with the best results?
Value over long run!
HTML 5 or not, all UI automation has to be focused on providing value, otherwise, what is the point? Long run is an activity of minimization of maintenance costs of updating tests while the system is evolving. Thus teams handling automation are to focus on validation of business-level features and requirements. With HTML this means features that are or may be a part of any high-value functional slice.
And I am not writing about Dungeons and Dragons. Usually drag and Drop is not something I would be recommending but with something as delicate as UI automation up may be down and down may be up. But you are still to be smart with such an approach. No new lead may be created without a contact dragged in thus automating that part will be of extreme importance for a test. But focus on the basic drag and drop operations only like testing new contact creation. On the other hand checking for things like ghost (you know, the ones that are the transparent copy of the picture you are dragging) images is simply pointless.
Testing something provided by a third party like a browser is not something you would wish to spend several extra hours at, right? Thus you are to think twice before automating something. Adding testing that is supposed to validate something that is a part of any browsers understanding of HTML (like the input fields) may be required only if t=you have a specific task of determining whether any browser’s understanding of HTML is changed or broken.
Media elements of HTML 5
Thus, to keep the long list short:
Only high-value slices of functionality do deserve to be automated
Don’t automate something that is not going to change to often
Do not automate third-party functionality
API test infrastructure may assist with minimizing impacts and complexity of changes
UI automation is never easy and not always necessary