The One With All The Names

A lot of testing is simple creativity. Everyday we get opportunities to be creative, whether testing an in-depth scenario we thought of earlier, doing some exploratory testing, or perhaps sitting in a meeting and discussing different options for a particular workflow. Where I always enjoy being creative, is when I have to set up my test data. However, there are important things to remember while testing and using test data, so that you can be more efficient to yourself and your developers. Let’s talk about Name fields.

What’s in a Name?

Most software products have some form of data entry involving personal information, such as a name, email, phone number, etc. These fields are often required in order to continue the workflow, so it’s important to use something that is quick to enter for testing efficiency, but also memorable for later use. These fields also need to be tested in other ways, such as the allowable characters, overall length, and duplicate entry.

It is useful while testing, to have a few different names prepared in order to meet different scenarios. It’s also important when demoing your products to different users, to use names that make sense and are not distracting, depending on who you’re talking to.

The Good

When testing my products and using data that only I or my development team will see, I like to use character names. I use Homer Simpson and his wife, Marge, with three kids: Bart, Lisa, and Maggie. The all American family that fits into most scenarios without problems. This way, when I log a bug about children not returning in a personal profile, a developer can quickly triage the bug and know the expected results: that I should have three kids, their names, genders, etc.

I will also stick with a theme or category when testing names, because when I need to pull up data in the database or the UI, I can quickly see if someone doesn’t belong. For these scenarios, I sometimes use superheros, like Clark Kent and his wife, Lois Lane. Then I’ll add a bunch more users to the product like Batman, Robin, Ironman, Spiderman, and many others (crossing universes is not a problem for me). Using names of interest makes testing repeat activities fun and exciting.

The Bad

When demoing a product to another team, especially upper management, it might not be in good taste to use a distracting name such as the Simpson family, but rather something more generic like the Smith family. This is especially important when doing usability testing with our end users, because a simple misspelling or clever use of a family name, could result in a poor usability session, or distract the user from providing all the necessary feedback that we hope for.

We find it works best during training sessions, to use basic names like John Smith and his wife Jane. This way, people are able to read the names, quickly identify who the users are and their marital status or genders, and then move on to important information.

Sometimes random name generators are fine as well, but if you aren’t careful, you can get names that aren’t really names, but more just words. Or you can end up accidentally creating someone famous. This can also turn an important conversation into a distracting one, when the name turns out to be Quail Bird, John Hamm, or Donald Trump. If we need names for a demonstration, it’s important to review the list of randomly returned ones, and edit any that might take focus away.

Additionally when using random names, it doesn’t represent anything or mean anything to the tester or developer, so when needing particular information, it can get lost when thinking, which user was that, or I can’t remember the person’s name I was using. That doesn’t mean it’s not helpful to have randomly generated names sometimes, but it’s important to remember who you’re using in what tests.

The Ugly

I have made the mistake of using very poor names in my testing before. Sometimes I will need to get through the data entry form or create a quick name, so that I can test something important down the line. I will enter a name like a a, b test, or lfdjsio asdf. Most times these are not a big deal to use and can allow you to move on through the form, but sometimes I need to get information back from the UI or the database, and I cannot remember who I was testing with. These type of names mean nothing, and our relate-able brains do nothing to store the name.

These are also much more difficult for a developer to recognize the scenario, and triage a bug against it. They don’t provide context to the problem, and don’t mean anything to a name, so this can actually turn into more questions like, is this a name or just some random data?

The biggest problem I’ve seen when people demo their product with names like this, is it doesn’t provide context into the UI. Let’s pretend for a moment that we are showing a user’s profile and personal information, and at the top left of the page, it says:

dsaflk safdjlk
9999 dfslakj fds
fdsafddfsdf, WI 12345

A user might be able to gather from that, that it’s a first and last name, and their address, but it doesn’t provide any value towards the conversation, and takes peoples thoughts away from the goal. Now let’s use a good example:

John Smith
9999 S. Theodore Drive
Franksville, WI 28876

Right away, a user will see this, understand the context, and be able to move to important things. Also, when they are looking at the UI, they will know what information they are expecting, and not be caught off guard by random letters and numbers.

Testing the Name Fields

All of the above is important information when using names during testing or demonstrations. However, it’s extremely important to thoroughly test the name fields on a form, during the testing cycle. Entering basic names like Homer Simpson should pretty much always work. If there was a bug for not accepting this value, I would be shocked. But there are a lot of names out there in the world, so here are some examples of things to test:

Very long names

Most people’s names are fairly short, 10 or less characters. But there are a lot of examples of people’s names that are 15-30 characters, and depending on the region of your product, you could get even longer. It’s important to test length to ensure the data doesn’t truncate, or if it does, that it’s intentional.

Hyphenated names

More common with last names, but occasionally there is a Mary-Jo, John-Paul, or Anne-Marie. Don’t forget this when testing to ensure the data can be stored and returned appropriately.

Names with punctuation

Similar to the hyphen, the last name is a more common scenario. Be sure to test names with apostrophes like O’Brien and O’Connor, or umlauts, tildes,and many other (but not all) foreign characters. Examples like Chloë and Beyoncé should be tested.

Duplicate names

We all know someone with their first and last name the same. Be sure to test this, as well as two users with the same exact names. Maybe they’re strangers, or a father-son combo.

This is definitely not an all encompassing list, but should kick start your testing efforts to ensure your system is fully supportive of it’s users. It’s important to have bug free software, and creativity while testing is often the first place to start. Just remember who’s going to see your data and when to use appropriate testing data.

What is your go-to name or theme when entering test data?