The CANYON.MID simulator

Want to relive the moment you first heard the dulcet FM synthesizer tones of the Yamaha OPL3 on your fancy new multimedia computer with Windows 3.1? Take a Trip Through the Grand Canyon again at http://canyonmid.com!

Special thanks to:

• The creators of DOSBox and the Windows 3.1x DOSBox Guide
• Jeffrey Hayes of Tvdog’s Archive for giving permission to use a photo of his Tandy 1000 RSX

Forgery(:credit_card).type
# => "Visa"

Forgery(:credit_card).number
# => "4539750423451972"

Forgery(:credit_card).number(:type => 'Visa', :length => 13)
# => "4556180133982"

A few interesting things I picked up along the way:

Hans Peter Luhn, responsible for at least one number in your wallet

• The anatomy of a credit card number (validation of credit card numbers always seemed like magic to me, but not any longer!):

  6011475432471140

  • 6011 — the IIN or prefix — these belong to different card issuers (for example, this is a Discover Card)
  • 47543247114 — the account number — normally assigned by the issuer to an individual customer, Forgery creates this at random
  • 0 — the check digit — a checksum from the Luhn algorithm
• This was my first experience writing comments for machine-generated documentation (RDoc). I think it looks great, and could prove very useful on other projects.
• I learned that one of my go-to Ruby methods for test automation, choice, has been deprecated. Thankfully, it was simply renamed to sample, which is available in backports.
• This was my first experience with RSpec, too. I like it — it seems very similar to Test::Unit (which I’m more familiar with), but with a more human-readable syntax. As a result, you end up with more meaningful tests and test failures, because behaviors are being defined instead of functions.

Finally, big props to Graham King and Celestino Gomes, whose knowledge and code I borrowed heavily from.

When I attended CAST 2011 this year, I was given a really neat opportunity: to present! I selected Sinatra as my topic, for a few reasons:

• Its low barrier to entry (easy to learn and free)
• I had a few interesting experiences with Sinatra to share
• I wanted to demonstrate that testers could write useful code that wasn’t automation

The presentation (in 3 parts) went something like this:

#1: What’s Sinatra?

Since the audience was potentially a mix of coders, non-coders, etc., I wanted to lay some groundwork, including:

• What’s a DSL?
• What’s a web application, exactly?
• Why Ruby: its readability, the robust native string manipulation library, how regular expressions are tightly integrated, the vast repository of helpful gems

An early idea was to play “Final Countdown” while coding

#2: Live demo

Next, I gave a live coding demonstration (I’ve since been told that I was…brave for trying this). There were four distinct steps:

1. A static response (essentially, the example on the Sinatra home page)
2. A dynamic response
3. A dynamic view (ERB)
4. Dynamic data (JSON)

#3: Examples

I shared 3 examples where Sinatra saved the day:

1. An e-commerce payment gateway that we had to work with was in many respects a “black box”, and it was drastically limiting our ability to test. We understood how the requests and responses worked well enough to build a replica in Sinatra, however, giving us the testability features we needed, including:

   • Logging
   • Recall of past transactions
   • “Magic” functionality (ex. getting any gift certificate amount you wanted)
   • Error simulations (ex. internal server errors, connection timeouts, etc.)

2. The diverse set of tools used by my team at Interactive Partners led to an unfortunate case of information siloing, but thankfully they all had APIs, so a Sinatra application named iP Relay was created to help “glue” them all together, for example:

   When David, one of our developers, does a deployment using Capistrano:

   > cap deploy

   Our faithful chat servant Botsworth announces it to the team:

   Botsworth: David Stamm deployed 3.16.1 (023c968) to SHO production

   Or, when he makes a commit with a message in this format (with the square brackets at the end):

   Bug #1941 (a bug that will live in infamy) — Fixed incorrect link URL. [bug: 1941, status: resolved]

   

   Screenshot of the "Testing Test"

   The following actions are carried out in our bug tracker, Bugzilla:

   Add comment to bug #1941, change status to “RESOLVED”.

3. When hiring, without access to old bug reports or test plans, it was difficult to evaluate how well candidates could find and report on bugs, so a Sinatra application named “Testing Test” was created to help test the testers. The person we ended up hiring found all of the bugs we intended to be in there, and even some we didn’t!

Slides

Finally, the slides shown to the audience, for your viewing pleasure:

tablr is a lightweight, quick ‘n dirty interface to the main capabilities of TJ Holowaychuk’s Terminal Table gem. I built it because I like pasting snippets of relevant SQL tables, CSV files, or URL parameters (from Fiddler’s WebForms view) into bug reports (Bugzilla comments are plain-text, and in a fixed-width font), for example:

Parameters sent to http://api.twitter.com/1/statuses/home_timeline.json:

+----------------------------+--------------------+
| name                       | value              |
+----------------------------+--------------------+
| max_id                     | 113545308612464640 |
| count                      | 21                 |
| include_entities           | 1                  |
| include_available_features | 1                  |
| contributor_details        | true               |
| pc                         | true               |
+----------------------------+--------------------+

If you’re a Bugzilla user in particular, maybe you’ll find it useful, too!

Source code available on GitHub.

“I want to get online…I need a computer!”

Exploratory testers, what if you could easily:

• Plow through lengthy registration forms in seconds
• Overload comment boxes with millions of words
• Assail address books with a heaps of ugly special characters

To learn how, check out Trish Khoo’s blog post, Go faster! Linking data generation to hotkeys. Using my own bubblegum and duct tape, I managed to wire together the following:

• AutoHotkey, sometimes using its InputBox function to collect parameters before returning a result:

  

• A Ruby random data generation gem named Forgery

• My fork of Anthony Long’s picka random data generator — the reason for the fork was, instead of generating data that will always pass form validation (better for automated tests), generate data that will usually pass form validation (better for exploratory testing).

  As an aside, one reason to love picka: its sentence function, which pulls text from The Adventures of Sherlock Holmes, totally of out of context (much more entertaining to read than lorem ipsum):

  He rose as he knew was in a corner a scissors grinder with his compasses drawing a circle with Eyford for its own fields filled for the world

Screenshot of the skin

Here are the skin’s main improvements over “Dusk” (on which it’s based):

1. Slimmed-down footer: only includes saved searches (instead of just another copy of the header)
2. “Heat” shading for priority and severity values
3. Brighter, fresher colors, copied from inspired by Lighthouse
4. Browser icons (mapped to “Hardware” values)
5. Wider search field, because QuickSearch is awesome

Harry Robinson likens his Computer-Aided Exploratory Testing to using probe droids

Exploratory testing isn’t necessarily all manual testing. In fact, I’m always looking for opportunities to extend my reach and increase my efficiency with automation. It’s like putting on a pair of night vision goggles: it’s still me and my brain, simultaneously learning, designing, and executing tests, only able to see things from more perspectives at once.

If you’re not familiar with the Fiddler Web Debugger, its core features are:

• inspecting HTTP traffic
• setting breakpoints
• manipulating (“fiddling” with) data

I don’t believe it’s traditionally thought of as a web automation tool (like Selenium or JMeter), but there’s a customizable rules file named, oddly enough, CustomRules.js that can be modified to perform automation as you perform manual exploratory testing. Below are two extremely simple modifications I’ve made that have aided my exploratory testing a great deal. Please feel free to copy, modify, be inspired by them!

Example #1: JSON-RPC error detection

// Is this the domain we're interested in (foo.bar.com), and is this a JSON response?
if (oSession.HostnameIs("foo.bar.com") && oSession.oResponse.headers.ExistsAndContains("Content-Type", "application/json")) {
  // "error:null" is present in the response
  if (oSession.utilFindInResponse("\"error\":null", false) > -1) {
    // Turn the line in Fiddler green
    oSession["ui-color"]="green";
  }
  // "error:null" is *not* present in the response
  else {
    //Turn the line in Fiddler red
    oSession["ui-color"]="red";
  }
}

A few of our applications use the JSON-RPC standard for their web services. A rule of thumb I’ve developed is: if an error occurs, something other than “error: null” will be present in the response. When added to the OnBeforeResponse function in CustomRules.js, this code simply turns the request green or red in the session list based upon this rule:

With Fiddler up on my other screen, any time unexpected behavior is exhibited by the front-end, I only need to glance over and look for red to see whether or not the back-end web services are somehow involved.

Example #2: tracking request highlighting

if (oSession.HostnameIs("www.google-analytics.com")) {
  //Turn the line in Fiddler gold
  oSession["ui-backcolor"]="gold";
}

Every web application we build has some form of tracking (sometimes only in certain environments), and whether it’s event tracking, tracking activity within a Flash interface, or just normal page tracking, it’s been valuable for me to have these requests stand out in the Fiddler session list, like so:

When added to the OnBeforeRequest function in CustomRules.js, the code above simply turns any request to Google Analytics gold in the session list. If selected, Fiddler’s WebForms view then provides an easy way to inspect the parameters being sent (which can be useful if you don’t have access to the analytics tool itself).

In March of 2010, I was commissioned by the New York Public Library to write a track for their new employee orientation video, “Best of All Possible Libraries.”

The title of the track comes from the video’s introduction, given by the library’s president, Dr. Paul LeClerc. Looking out over the famous Rose Reading Room, he emphasizes that the greatness of the institution ultimately derives from “the staff of the New York Public Library [who] put this place together and every single day, day in and day out, season after season, make it work.”

Make It Work

The film includes “chiptune” music by the Super Madrigal Brothers, foley art and 8-bit sound design by me.

Golden Grams