I’m sure most people reading this blog have at least some experience with automation testing tools for web UIs. And I guess most of us can agree that no matter what testing solution we use, we all follow similar algorithms when automating UI testing.
UI testing automation is all the fuss today. In a way, this is due to an advent of new solutions that promise to outperform the “tried-and-true” tools of the past years. But how many of these automated testing tools (both new and old) are CI-friendly? Besides, how many of them are good at handling visual testing of websites and web apps?
Let’s see what the market of UI automation testing has to offer in the way of CI support. But first, let’s answer the following question.
Image credit: SoapUI
Test-driven development is awesome, unless you’re dealing with automated GUI testing.
Sure, test-driven UI development is technically possible, but TDD isn’t exactly ideal for situations requiring full functional tests, and full functional tests are indispensable to GUI testing. For this reason, using TDD for UI borders on overengineering. Choose this path, and you’ll end up working with mock objects or project object models (POM), adding new layers of complexity to your project. And in many cases, you won’t be able to tell if doing this will pay off.
When it comes to UI test automation for web projects, element locators can become one hell of an issue. But is there anything you can do about it?
The thing is, poorly-written locators are just a part of the problem. Writing good locators is, in fact, not that difficult. After all, good locators are merely a matter of either accessing IDs or building robust CSS or XPath selectors. And you can always get your developers to throw in a couple of extra IDs, right?
Now that the CI integration plugin has been successfully rolled out, it is time to recall how it all began… Ready for a tale about defeating a horde of CSS regression testing challenges with the help of a Jenkins server and a visual QA automation tool?
Why did we need CSS regression tests on our CI
Our team has realized the necessity of automating the visual regression testing process last winter, when our other product AjaxSwing gained a significant number of new users, who were actively requesting improvements. A new version was released each week, sometimes even more often. AjaxSwing generates web UI for desktop applications so you can imagine how much visual UI verification we had to accomplish each time a build was ready. It just seemed never-ending. We had unit tests in our continuous integration environment running against every new build, but they didn’t help with verifying the visual aspects of the UI such as CSS, formatting and layouts. That’s when our QA team decided it is time to try our new automation testing tool Screenster in real action, despite it being in its early Beta at the time.
Are you overloaded with web UI regression testing and finding that manual visual testing is a pain? You definitely need some automation testing tool and guess what: we have just the thing for you! Skeptical about tools abilities to handle complex sites that use not just plain HTML, Web 1.0-styled pages? You should be, because most of them suck at it 🙂 Let me demonstrate you how I built UI regression testing automation process for Gmail inbox (let us imagine we are developing new Google Mail UI) in 15 minutes.
Last week I had to record a bunch of tests for a site that required a user to be logged in. Which is why I would like to talk about one Screenster’s feature which was most helpful for me during all that time. So, let me introduce the Feature of the Week in our blog: the ‘Extend’ command!
What regression testing challenges do you typically face when automating UI tests? And more importantly, how do you overcome these challenges? This post sums up our experience of dealing with UI regression testing and its pitfalls. But there’s one more question to ask before we can proceed: do you automate UI test in the first place?
I’m sure you know that quality control is inseparable from product development process. Some good amount of time and resources should be invested into it. New UI functionality must be covered with tests as soon as it is ready. And it is not enough to verify it once: each time an important change is introduced, the UI regression testing phase must follow.