Automation testing of Gmail UI

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. My objective was to get unwanted changes highlighted as bugs while leaving out any types of expected behavior. When a new email is received, the correct behavior for an email UI is: New mail gets added to the inbox Sender’s ID or signature are displayed next to the email Date and time is displayed for sent and received mail Alert icons (like the “!” sign) displayed on tabs where new items appear Such UI changes are expected and an automation testing tool should identify them correctly. But since a human-like AI still remains far from being officially released anywhere, we could be content with a tool that ensures that expected changes... More

Here’s how you can edit automated UI tests with Extend

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! Each tester has to employ a few different test environments from time to time. CSS regression testing process often includes checking several product versions at once. Naturally, one does not want to re-write tests anew in order to run them on another server and/or with different user credentials. Why do that if they just require a couple of actions to be changed: the starting URL and the login + password combination? In such a case you can edit the test steps but there is a faster way with Screenster - click on the ‘+’ button at the right side of this test on the Project View page, and the ‘Extend Test’ popup menu opens. How does it make UI regression testing simpler? With this command we are actually adding a new step which launches a base scenario with new parameters. Now it... More

UI regression testing challenges solved

Quality control is an important part of product development process. Some good amount of time and resources should be invested into it. New UI functionality must be covered by tests as soon as it is ready. And it is not enough to verify it once: each time an important changes are introduced, the UI regression testing phase must follow. Manual UI regression testing tends to take more and more of the project time. A common solution for a big project is to automate this process. However, the UI regression testing automation, with all the benefits it brings, comes at a price. Firstly, you need to invest into the automation in order to reap benefits later. And it could take a long time at the initial stage. The fact is, you need to spend resources to set up a framework such as Selenium, to build the tests (which should also be tested themselves) and to run them properly and return useful data. These resources could be spent to speed up manual visual regression testing instead. Secondly, the completed automated visual regression tests should be supported afterwards. Their coverage may become insufficient as the product grows and evolves. Sometimes tests should be amended... More

QA automation for Ajax UI tools: testing AjaxSwing with Screenster

AjaxSwing automatically converts Java desktop applications to web applications. It was the first product built by our company and is still the only platform capable of automatically running Java Swing apps on mobile devices running iOS and Android. For the first 10 years (10 YEARS PEOPLE!) we were struggling with changes to AjaxSwing because we could never truly understand the effects of each code change. We wanted to automate the UI regression testing with Selenium and tried a few other alternatives, but since none were testing the page visually these tools failed to detect broken CSS and HTML formatting. Touching anything in Java or CSS code was like walking on a minefield with delayed explosions but real pain. Screenster, a visual regression testing tool gets into action! We have now been running pain-free with Screenster as part of our CI. We use it for visual testing, CSS testing and most of the functional testing. Given that Screenster ensures pixel-perfect regression testing, our developers are now fearless. We've built over 50 tests that go over common scenarios, and with TDD we keep adding new tests every week. Every time our CI catches visual differences of a few pixels, cropped borders or... More

Visual CSS regression testing tool

The case for CSS regression testing is very simple. When you change a class attribute, how do you know which elements and pages have you actually affected? CSS changes might very well be the hardest thing to test because unlike JavaScript and backend development, there are no compilers and unit tests that act as a safety net. The only way to find what’s broken is to eyeball each page, which we all can agree is error prone and far-from-fun task. In 2016 do humans *really* still have to slave in front of a monitor for hours doing monkey testing?? I’m here to tell that there IS a better way that is pain-free! Companies like Google, HomeAway and Kaspersky have already signed up so let's see what the buzz is all about. Automating CSS testing with Screenster Screenster was born out of pain. Our company's flagship product AjaxSwing generates web UI for desktop apps. Making CSS and rendering changes was like a sumo wrestler walking on egg shells - you pretty much know you've broken something, but you don't get to know until you shipped the product, customers upgraded and someone reported an error. Visual changes were some of the hardest... More

Screenster Roadmap: more regression testing features, better UX

Screenster team has big plans for the future and many fresh ideas of improving the process of visual regression testing. This roadmap includes what we are working on and what we want to accomplish. Release 1.1 Target date: Summer 2016 Suites that allow to organize tests into a group Copy/Paste for suite, test and test step Concurrent test execution URL override for running tests against a different environment UX updates for easier navigation Command sets that group test steps automatically for faster execution   Release 1.2 Target date: Fall 2016 Environments with parameters and baselines Smart approve to baseline across multiple tests and steps   Release 1.3 Target date: Winter 2017 Execution on the cloud Internet Explorer support Versioning of tests Branching/Merging of tests Verification modes: text only, nothing [raw] Want to try Screenster on the cloud? Try Online [/raw]

Screenster 1.0 is released! UI regression testing made simple

We have FINALLY released the 1.0 version of Screenster! It’s been a long road but we had to make sure we have a product that works. Screenster is now ready for basic and smoke testing and there is a ton of new features on the way. All of the core features are now working: Visual baseline with changes approval Record/playback of visual tests Ignore regions for dynamic UI Smart dates handling Extend/parameterize tests Smart locators with auto-maintenance Jenkins integration and REST API We are already working on version 1.1 It will have the following cool new features Concurrent test execution Copy/paste everywhere Simplified URL overriding Improved UX Download Screenster server and let us know what you think! [raw] Want to try Screenster on the cloud? Try Online [/raw]

Selenium alternatives for testing automation

Love and Hate with Selenium If you spend enough time with automating web applications, you will most likely develop a love/hate relationship with Selenium. The truth is that it’s pretty much the only game in town to drive the browser through the API. That’s where the "love" comes from - you can start writing cross-browser code in your favorite programming language in a matter of hours. Sweet! But spend enough time doing that for a real world application, and you will discover the ugly side of this coin that at times make you pull your hair out. In my experience the following 6 pain points are near deal-breakers for automation with Selenium. 1. Selenium tests are unstable. WebDriver libraries version trail the auto-updating browser and there’s always something small that doesn’t quite work. Often when you get the new version of the Selenium libraries that is supposed to fix the issue, you discover that now something that used to work doesn’t work the same way anymore. Add to that multiple versions of browsers, and you are constantly chasing a moving target. 2. Good tests require good coders. Yeah, I’m sure there are plenty of good developers automating web testing through... More
WordPress Image Lightbox Plugin