Testing Functionality, Responsiveness and Rendering on Geico’s Responsive Website

Responsive web development requires detailed attention when incorporating testGeico responsive web development ing practices; the same (hopefully) code is intended to render on many screen sizes and operating systems/versions. In addition, HTML5 functionality may assume access to local sensors to drive a richer and streamlined experience, for example, automatic location detection, further complicating the responsive web test strategy. The testing matrix becomes sizable, while the time-to-test shrinks from increasing competitive pressure and the transition to agile.

In this article I'll show how to conduct multi-platform parallel testing when focusing on responsive web development, using Geico's responsive website as an example. In addition to a standard functional test, I will add the ability to validate the responsiveness of the site, as well as leverage Applitools' Selenium APIs to ensure proper rendering across different screen sizes. There's a code sample to complement this article: here.  

Setup

  1. In Eclipse, create a new project based on the Perfecto Selenium template (ensure you have the latest plugin)
  2. Convert this project to Maven, then TestNG, and add TestNG class. Make sure to generate BeforeTest, AfterTest and BeforeSuite functions. Also make sure to select tests to run in parallel when configuring TestNG.
  3. Add one or more @tests to your java code. In my project it's in GeicoRWDTest.java. For now focus on the functional aspect of things.
  4. Fun step #1, platform selection: fill TestNG.XML with the platforms you want to test on. I recommend using device characteristics (OS, version etc.) and avoid device IDs. You can add as many as you want, including browsers, as long as your licenses allow. If you don't know which devices/browsers to test on, use our digital test coverage index. Platform coverage is key when testing responsive websites.
  5. At this point your POM.xml is missing a few parts. Best to compare it with the one in the code sample.
  6. Last piece before the first run: add environment variables to your test
    Insert environment variables into TestNG
    Insert environment variables into TestNG
    1. Right click from your TestNG.xml file ->Run as ->Run configurations and add the following:
      1. PERFECTO_CLOUD: your cloud, ex.: mycloud.perfectomobile.com
      2. PERFECTO_CLOUD_USERNAME: your cloud username, ex.: dan@gmail.com
      3. PERFECTO_CLOUD_PASSWORD: your cloud password
      4. (optional, but you'll want it later) APPLITOOLS_API_KEY. If you don't have one sign up for free at Applitools.com and you will easily get it. If you don't want to add it, no worries, the project will work anyway.
  7. OK, time for first run! right click your TestNG.xml file, select Run as -> TestNG suite. Make sure to turn on Perfecto's dashboard in the views so you can see the devices/browsers running. Notice in the console on test completion you will get a link to Perfecto's new report (in my code I highlighted it with "########### ========>>>>>>>> Report URL:")
  8. Adding responsiveness measurement to the test: In case you didn't know, Perfecto offers OCR and image analysis technology to validate correct rendering of specific elements on the page (beyond native objects). You can also measure the time from when you clicked on the previous page until the new one is rendered. The magic is done in PerfectoUtils.Java, specifically in ocrTestCheck and getUXTimer functions. For convenience I put them together into one function, where
      1. Driver: the remote web driver
      2. Text: the text you're looking for. Note don't use text that appeared on the previous page 😉
      3. Threshold: percent confidence, 0-100, I usually use 99
      4. Timeout in seconds
    So a complete section would look like:
    OCR validate and get UX timer
    OCR validate and get UX timer
    The outcome:
    responsiveness measurement of Geico pages on Android (in milliseconds)
    responsiveness measurement of Geico pages on Android (in milliseconds)
     
  9. Adding rendering validation to the test: This is the real fun.
    1. Let's start by introducing ApplitToolsHelper.java
      1. Static "batch" variable to help you collect your tests into a single batch. Note that the batch can be driven from Jenkins or created new from inside the test:
        SetBatch from Jenkins or locally
        SetBatch from Jenkins or locally
      2. Local eyes variable, this will help us do the rendering validation. Note: batch is global across all eyes instances.
      3. The constructor validates you have an API key (remember APPLITOOLS_API_KEY from section 6?), and if so, it will
        1. Instantiate eyes (for each thread)
        2. Assign it to the batch
        3. "Open" the eyes to the driver
          ApplitoolsHelper constructor
          ApplitoolsHelper constructor
      4. "Close" eyes essentially closes the eyes. What you should know is that eyes are designed to fail the test if Applitools finds material differences in the images. You can decide if that's what you want to do or just get the Applitools report URL
        Close eyes
        Close eyes
      5. Lastly, checkWindow validates the window you're using. Best to add a tag in there. Applitools correlates images to the baseline by a number of assets, including the tag ("Geico home"), OS, version, screen size etc.
    2. Main code changes (GeicoRWDTest.java)
      1. In the "BeforeSuite" you want to initialize the batch so it's grouping all the eyes instances
      2. In "BeforeTest" instantiate ApplitoolsHelper
        Create ApplitoolsHelper instance before the test is run
        Create ApplitoolsHelper instance before the test is run
        Setting the batch before the test and closing the driver at the end
        Setting the batch before the test and closing the driver at the end
      3. Hopefully everything went well, you should be able to add applitoolsHelper.checkWindow(tag) everywhere you want an image to be taken
        Add visual checkpoints to your script
        Add visual checkpoints to your script
      4. In "AfterTest" you want to get the Perfecto report URL, the Applitools report URL and close the eyes 😉

Don't want to work so hard?

  1. Clone https://github.com/AmirAtPerfecto/GeicoRWD
  2. Refresh the project so the POM applies
  3. Enter environment variables (Step 6 above)
  4. Run

What did I learn?

  1. Adding render validation and responsiveness to a functional test is real easy. It doesn't add much time to parallel execution of a test. Totally worth doing.
  2. I was struggling to select which platforms to use. Perfecto digital index really helps.
  3. Timing between iOS, Android and Chrome are really different. Worth watching and tracking.

What's next?

  1. Well, we're about to add HAR file creation to mobile. While on browsers it's easy to generate those, less so on devices. Imagine you can compare HAR files on mobile and desktop browsers and fine tune what's really bogging down your site load.
  2. You can also get page load time from Selenium logType.PERFORMANCE. read more here.
  3. Generally speaking getting stuff from the Chrome developer tab, such as network, timeline, security analysis etc. trust me, lots of interesting stuff there!
    Chrome developer toolbar for Geico's website
    Chrome developer toolbar for Geico's website
  4. Lastly (on my wish list), Perfecto recently introduced Wave toolbar in Chrome browsers. It'd be great to get the accessibility report straight into the test.
    Wave toolbar accessibility analysis of Geico's responsive website
    Wave toolbar accessibility analysis of Geico's responsive website
Tags: , , , , ,

Share Your Thoughts!

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

Love to learn about creating top notch digital experiences?

Get the latest news, tips and articles delivered right to your inbox.