Chris McMahon's Blog

Search This Blog

Posts

Disclaimer: In my career I have done most of the things I describe below, but never tied them all into one project. The following should be possible:
Testing a System
Suppose we have a software system of reasonable complexity. Suppose our
system is comprised of a front end with a user interface (UI) and a back
end, thus a client and a server. The front end and the back end communicate
via an application programming interface (API) of some sort. This is a
common architecture of many software systems.

Suppose further that our front end and our back end are well-designed.
They have unit tests, and meet whatever definition of quality you would
want to apply.

Because our system is reasonably complex, we want to have a suite of
end-to-end tests that exercises the entire software-and-data stack, that
demonstrates that the users can do the things they need to do, and that
the front end and the back end are communicatin…

Possibly the most important aspect of an agile process is the
retrospective. A retrospective usually happens in a team meeting,
generally at the end of every agile iteration or sprint. While there are
any number of ways to run retrospectives, the object is to discuss
three questions:

What is working well?
What is not working well?
What should we change?

The first question tends to be the easiest to answer, and it is tempting
to just skip it, but that is dangerous. It is every bit as important to
celebrate the team's success as it is to grapple with the team's issues
and problems. Positive reinforcement is more powerful than negative
reinforcement.

The second question also tends to be easy to answer in teams where the
members feel safe to discuss work honestly. It is important to surface
problems so that the whole team is aware of the current issues and why
those issues affect the work.

There is a sentiment in software development that if you do not have a working BDD practice then Cucumber is just unnecessary overhead. I understand this position, but I disagree, based on my own experience and my own practice. I find Cucumber is particularly valuable in automated browser tests.

I've been using Cucumber for automated browser tests at work just about every day for the last six years or so. At the same time, I have never worked with a full-on BDD team. Beyond BDD, here are three aspects of Cucumber I find particularly valuable:

Cucumber creates a low barrier to entry for anyone at any time to contribute and understand the project.Cucumber's Given/When/Then syntax provides a design guide particularly well suited for browser tests, especially using "When" in a particular way.When a test fails, Cucumber provides a plain-English description of what the test does that may not be immediately apparent from the code or the nature of the failure.I tend to write b…

Some of the Watir community has been discussing the history of the project. Here I try to set down some notable things that I remember about that time.

We have to start the story of Watir with Ruby. The first English documentation for Ruby was published in 2000, and it garnered a lot of interest, particularly as it was so amenable to creating Domain Specific Languages (DSLs), which caught the attention of a number of people working in testing, and in the Agile world. Python 2.0 also came out in 2000, and the dominant scripting language at the time was Perl.

Of all the browsers available at that time, only Internet Explorer exposed an API for automating browser actions, via a COM interface. In 2001, Chris Morris published a Ruby library that exploited IE's COM interface called WTR, for Web Testing in Ruby.

At that time, Open Source software was often seen as inferior or even downright suspicious, and was poorly understood by most businesses. Test automation products were exclusively …

This is the story of a really great project I did while working for Salesforce.org. I have done a significant amount of remote pair programming over the last ten years, but this project was extraordinary in a number of ways. For one thing, it was a really complicated problem that demanded a technically advanced solution. For another thing, it took almost an entire year to finish-- one hour per week.
The Problem
I will try to give you the background in a way such that your eyes don't glaze over: in order to work with data in a Salesforce instance via the API, you address "Objects" and "Fields". (These are actually tables in a database that may be addressed by a poor and crippled version of SQL.) For example, here is a description of the Account object whose first field is AccountNumber.

If you are a developer on the Salesforce platform, you can add your own Field to the Account object, but you have to append '__c' to it, like "MyField__c". Yo…

As of January 2018 I resigned my position as "Senior Member of the Technical Staff, Quality Assurance" at Salesforce.org. I have more than twenty years experience in testing user interfaces and APIs across a wide variety of platforms. If you would like to contact me, my DMs on Twitter are open or by email at christopher dot mcmahon at gmail. I do not use Facebook, LinkedIn, or Skype.

I have been working remotely for more than ten years. I enjoy telecommuting, it suits me nicely. In the past decade I have lived all over the western United States, including some time in Hawaii.

Here are some points from my career that help tell the story of how I came to be here today:

In 1997 I started testing 911 telecom location services, life-critical software for police/fire/ambulance dispatching for most of the USA. I tested these systems through Y2K and beyond. We saved the world. Don't let anyone tell you otherwise.

Managing test data is one of the most difficult parts of good testing practice, but I think that managing test data receives surprisingly little attention from the testing community. Here are a few approaches that I think are useful to consider for both automated testing and for exploratory testing.

Antipattern: Do Not Create Test Data In The UI
But first I want to point out what I think is a mistake that many testers make. When you are ready to test a new feature or you are ready to do a regression test, or you are ready to demonstrate some aspect of the system, the data you need to work with should already be in place for you to use. Having to create test data from scratch before meaningful testing begins is an anti-pattern (and a waste of time!), whether for automated testing or for exploratory testing.

Create Test Data With An API
This is usually my favorite approach to managing test data. Considering this scenario in the context of an automated test, I usually will have a '…