Wednesday, February 4, 2015

More things I learned at GTAC (Day 2)

Editor's Note: I'm sorry that this took so long for me to click "Publish" on!

Here are my notes from the second day of Google's Test Automation Conference (GTAC) back in October.

Enthused About: Test Suite Reduction

Software testing can be a bit like drinking from a fire hydrant. For every "degree of freedom" in an application, the number of potential test cases for that application increases exponentially. To cope with this explosion, one of the most challenging (and consequently, the most interesting) activities carried out by a tester is to reduce the number of test cases required for "proper" verification.

All of this boils down to a rather classic question from software testing: How much testing is "enough"? As with most interesting questions, the answer is some form of "it depends." At a high level, though, I like to define an application-specific notion of "enough" in some terms of coverage.

Wednesday, October 29, 2014

A bunch of things I learned at GTAC 2014 (Day 1)

[ Note 0: This became very long.

Note 1: I will try to come back and properly link to the efforts/projects mentioned in this post, but for now, you can "google" most of these and find them successfully.

Note 2: These observations have my usual biases, especially web application testing. Apologies in advance to mobile testing people doing really interesting things. ]

Monday, October 20, 2014

Short: Testing

Testing is the process of evaluating whether an artifact fulfills its requirements. Effective testing depends on the ability to clearly define expectations and clearly observe relevant domains which can inform this evaluation. You can't test what you can't see.

Wednesday, September 3, 2014

HOWTO: Dealing with Data in Docker: A Dockerized Jenkins and Sonatype Nexus Example

My job title may say "Software Developer in Test," and my dissertation may be about "Model-based testing," but I'm afraid I cannot escape my true self - a CM guy. For whatever reason, I am passionate about Configuration Management. Every side-project I've ever worked on, the first things I want to get up and running are a code repo and a continuous integration build; THEN (and only then) the coding can begin.

I recently shared my enthusiasm for Docker, and I mentioned in that post that I would come back and share an example of data management with Docker. Here is that example, in the form of some work I recently did to get Jenkins and Sonatype Nexus working in their own Docker containers yet talking to one another and scripted in a stable, repeatable way.

If you're in a hurry, you can find a public Gist of my scripts for this example right here.

Tuesday, September 2, 2014

Enthused About: Docker

Recently, I've been exposed to Docker, a virtualization tool for Linux. Now, I've been a fan of virtualization for quite some time, but Docker has some additional features beyond the more traditional VMs (if you'll allow me to call them traditional ... always cracks me up to associate a relatively young technology with any sense of "tradition") that I find quite fascinating. Below is a short introduction, and five features of Docker that I am quite excited about.

Friday, August 29, 2014

Enthused About: Widget Libraries for Browser Automation

At work, we use Selenium WebDriver (specifically, the Java API) for browser automation. Last December, we released our internal library which builds on WebDriver. We call it Extensions for WebDriver, or ExtWebDriver.

Since its first release, we've done a number of additional releases with relatively small enhancements. We've also presented the library to a number of test automation interest groups, the largest of which was the Metro NYC Selenium Users Group. That talk is immortalized on YouTube.

Today I thought I would write about what I consider to be the coolest feature of ExtWebDriver - its widget library approach.

The Selenium community generally promotes the use of an abstraction called the Page Objects, whereby the code for interacting with a single page of a web application is split into objects. In the ExtWebDriver library, we ship with out-of-the-box components defined at least one level deeper than Page Objects, which we call Widget Objects. An ExtWebDriver Widget Object (or Widget Class) knows how to interact with a single Widget. Automation engineers can leverage existing, well-tested, and often reusable widget objects when writing Page Objects or their equivalent.

The current version of the library (v. 1.4 as of this post) ships with a hierarchy of Widget Interfaces and concrete implementations for a basic Element and InteractiveElement. We also have a set of widget objects for standard HTML elements like Button, Input, List, Radio Group, and Table. In each object, you'll find the methods you'd probably expect. For example, Table ships with getRowNumber, getTableColumnCount, getTableDataInArray, getTableDataInMap, getTableHeaders, getTableRowColumnData (for a specific cell in the table), getTableRowCount, and isItemExist. Perhaps the most useful objects are the base objects below HTML like Element and InteractiveElement.

For those familiar with WebDriver, you may ask why we don't simply use the base WebElement class and extend it directly. For one thing, there's no promise that ExtWebDriver won't do this in the future (our latest release included use of the By locator objects from Selenium's framework). For now, the abstraction layer between ExtWebDriver's widgets and WebElement does isolate users of the library from the particulars of WebElement that may otherwise not be pertinent to a particular widget. The Element base class does provide a getWebElement method for direct access to the WebElement underlying any widget object instance.

As a designer, developer, and maintainer of browser automation solutions, I find the reusability of widget libraries attractive. The testability of UI front ends continues to be a driver for framework development as a whole (consider the "Testable" bullet on the AngularJS Homepage), and if we could aim to develop widget libraries for popular frameworks like GWT, jQuery UI, and Bootstrap, I think we could all (as the automation community at-large) more effectively minimize the tedious rework that many of us now carry out in isolation. I can envision frameworks in the future which deliver automation capabilities alongside every feature or UI widget of a framework. Automation-ability has become nearly synonymous with the ability to test effectively for fast-moving teams.

By the way, ExtWebDriver has plenty of other features, too! Another contribution of ExtWebDriver is its SessionManager, which includes a property-file based instantiation of thread-safe WebDriver sessions. You can get started with a quick example right here.