Unleashing the Hamlet

Ladies and gentlemen, the infamous Hamlet Test, explained for your edification and as a tool for your arsenal. Some might call it a mechanism for Boundary Analysis, but it’s more than that. It’s just plain mean.

The use case, if you need one (oh, and how you’ll need one since “rock star” developers will tell you this would never happen in real life so he can, instead of writing flawless code, can get back to YouTubing): Back when I was a technical writer, I used to write the documentation by using software. Hey, I know, that’s an odd concept; most technical writers, if they exist for an organization, will take what the developers give them and put it into a serifed font and call it a day. Not me, I actually used the software, which also explains why I had the second highest defect count in the company, above most of the full time QA people, but that’s another story.

So there I am, swiping and pasting data from the application into my text editor (UltraEdit, don’t you know?) while I’m rearranging a user’s guide weighing in at about 250 pages. I’m reorganizing procedures and how-tos, building new chapter intros, and whatnot, and I’m swiping and pasting from a massive Microsoft Word document at the same time as I’m swiping and pasting shorter strings from the application.

You can see where this is going, right? A never-in-the-real-world situation occurs. Instead of pasting a short string into an edit box, I dumped an entire chapter of the user guide into it. And it took it.

Friends, this was a desktop application written in Java. You know, Java. A couple years ago it was what all the cool developers did because it was a badge of honor to code in such an esoteric non-Microsoft language. The smart people used Java. Also, Java did not have the color-by-numbers safeguards offered by Microsoft IDEs to help developers not do something stupid. Like automatically accepting SUSs (Strings of Unusual Size). So they were playing without a net and without talc on their sweaty little developer palms.

It took the chapter, and although it took forever for it to return (or even repaint the screen), nothing crashed. So of course I wanted something bigger.

Hamlet is bigger.

I went out onto the Web and grabbed the full text of Hamlet by William Shakespeare (I do have an English degree, after all). I stripped it of all of its punctuation and line breaks and ended up with a string of 135,014 of the best characters ever strung together 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, damn that copycatting monkey who gets the whole thing correct down to the last parenthesis.

Yeah, well, that did the trick. Good night, and thanks for all the fish.

I logged a defect, of course, and no doubt it was right at the top of the developers’ list (right after watching the complete video of a guy going through all the levels of Pac Man without dying once).

So true boundary analysis means you check to make sure that values up to and just exceeding the limit are handled appropriately, right? So an edit box that’s supposed to have a limit of 255 characters can handle 254 and 255 characters without puking stack traces on my screen and 256 should either be limited by the control or should produce a nice validation message for the user. That’s how it works, I’m sure, in those smoking-jacket, pipe-smoking Victorian English QA shops where they’ve got time to drawl with accents about unfortunate events. In the real world, you’ve got 4 hours before the tech team is promoting it because the client set a hard deadline and, whoops, the tech team missed its internal deadline by 2 weeks (sorry, old chap). Hamlet will blast right through all of their mistakes.

Want to know if it’s going to fail? If you see a peal of ordnance is shot off in your desktop application means something’s going to give. If you’re testing a Web application, many browsers will just show a blinking cursor to the right edge of the edit box. This means someone has decided to save $5.99 by not installing a MAXLENGTH on the edit box. Click Save and let the fun begin.

And let the passive voice e-mails begin.

No Responses to “Unleashing the Hamlet”

  1. TheKiser Says:

    Well, it is nice(?) to know some things never change. One thing I have learned in 30 years of programming is the worst person to be testing code is the one who wrote it, myself included. Have ever heard the excuse: “It’s impossible to write idiot proof code because idiots are so damn inventive?”

  2. angelweave Says:

    If you have to be your own tester (as a developer), you need a set of “I always do this.” One of mine is to always set the maxlength, and I’m proud to say that that’s been a maxim before I was exposed to the Hamlet test.

    The other one is that you absolutely must not test immediately after you write the code. It’s like editing your own writing. Let it sit, and then try to forget you’re the buffoon who failed to check how your new module looks to a non-admin user…


  3. The QA Slayer Says:


    Edited by The Director when he fixed the issue that yes, by default, the user can enter up to 65536 characters in an unbroken string which will blast outside your layout.

  4. Director Says:

    Everybody’s a wise guy.

  5. Director Says:

    Try it now, oh lord developer, and see how fast a mere QA person can fix the issues you find.

wordpress visitors