The Hamlet Test, Explained

Recently, someone I worked with a long time ago mentioned the Hamlet test on one of my LinkedIn posts. Someone else I’d worked with commented because it certainly made an impression on the St. Louis development diaspora. Not everyone yet knows and fears the Danish prince exposing flaws in their software, so let me explain how it came about, what it represents, and why that’s important.

Back when I was a full-time technical writer, I ran and interacted with the software I was documenting. Hey, I know, that's an odd concept; some technical writers take what the developers give them, put it into a serifed font, and call it a day. Not me: I actually used and abused the software to try to explain it. I often logged more bugs than full time testers, but that's another story.

So there I was, swiping and pasting data from the application into my text editor at the same time that I was rearranging a 250 page user's guide. I was reorganizing procedures, building new chapter intros, and whatnot. My clipboard alternated between twenty or fifty pages of a Microsoft Word document and shorter strings of test data from the text editor.

Suddenly, a never-in-the-real-world situation occurred. Instead of pasting a single word into an edit box in the application, I dumped an entire chapter of the user guide into it and hit ENTER. The application accepted the chapter, and although it took forever to repaint the screen, nothing crashed. So of course I wanted something bigger.

Hamlet is bigger.

I have an English degree, so of course I grabbed the full text of Hamlet by William Shakespeare from the Web. I stripped all punctuation and line breaks and ended up with a string of 135,014 of the best consecutive characters in the English language. Why, when one of the infinite monkeys cranks this string out instead of the complete text of the play, he'll be my hero, not that copycat who gets the whole thing correct down to the last parenthesis.

Although the application could handle several thousand words from little old me, the play crashed it. And a legend was born.

Technically, the Hamlet test reflects a boundary analysis test. In boundary analysis, you check to make sure the application handles values up to and exceeding the planned limit. If your application expects a payment 90 days in the future, you test 89, 90, and 91 days. To test an edit box that expects an address of up to 75 characters in length, you test with 0, 74, 75, and 76 characters to ensure that the control limits it (remember the maxlength attribute and keep it holy) or that the application produces a nice validation message for the user. Hamlet is going to be too long for most normal edit boxes, and if you see the final stage direction (A peal of ordnance is shot off.) when you paste it into the control, go ahead and click the New button in your defect tracker.

The Hamlet test goes beyond strings. I once mentioned running a million line file through the import utility, and a colleague laughed and said that I didn’t have a million line file—which was true; somehow, in my cutting and pasting, I had 1,047,000 lines in the file. I once made an image file so large that it crashed my PC when I tried to open it before I could even try to upload it to the Web server. Fair warning to developers and clients: I have a better computer now.

Ordinary boundary analysis does not require making the application drink from the firehouse, but the Hamlet test does not just represent one type of test: it represents a whole philosophy. The whole of the software development process gears itself to what the user will or what the user should do—or what software development professionals think the user will do (see also: The Customer Vs. The User). The Hamlet test and its attendant edge cases explore what the user can do with the software.

User stories and acceptance criteria often state the goals of the software, the problems the user needs to solve, and the solution the software provides. Many times, the testing approach gears itself to validating those criteria. If the user can enter a user name in the User Name edit box, the test passes and the software is deemed Quality.

However, users will not use the software according to your design documents. Users will do what they need to do, sometimes using workflows they find themselves, and they will make mistakes. Although it might be unbecoming to think of your users as an infinite number of monkeys with an infinite number of keyboards, users will do what your software lets them do, not what your Rally tickets say. 

When I found all those bugs as a technical writer, I was going back and forth between screens in unanticipated ways because I needed to take screen shots that were just so, and the application didn’t like it. I was not doing what the user should do, but I was doing what the user could do to describe, in the manual, what the user should do.

So your testing needs to account not only for Hamlet. You need to test its boundaries, its limits, above and beyond and just to the right and left of expectations. You should never ask Why would a user do this? Answers include The user made a mistake or The user is malicious or at the very least mischievous or curious about what would happen. As I demonstrated back in those days at my first startup, even experienced users will make mistakes when distracted or multitasking.

Ask instead Why does the application allow this? Because you can learn more about improving overall quality with this question. Do you not use maxlength by default? Do you let the user type dates instead of using a date/time picker? Do your administrative screens go light on validation because you expect only system administrators to use it (I’ve seen the administrator duties handed over to temp receptionists—if you’re trusting that someone with a computer science degree will be setting up access rights in your system, you’re too trusting).

With a memorable name and premise, the Hamlet test keeps this philosophy in the consciences of developers I’ve worked with years later. Because it brings to mind Kenneth Branagh swinging from a chandelier, Laurence Olivier with Yorick’s skull, or perhaps Mel Gibson—this English major won’t judge you for thinking of the movies—you can more easily remember the Hamlet test than Boundary Analysis: The Motion Picture.