Apostrophe, Ampersand, Exclamation mark & Co.

Since I am in the testing business, I am "preaching" the use of special characters and umlauts wherever and whatever we test. 

Umlauts (ä,ö,ü) and chars like é,â, etc. are very common in Europe. In the US and elsewhere, you often see last names with a single quote such as O'Neill, O'Connor or, think about company names like Macy's and McDonald's.

Sometimes, we forget to include these characters in our tests and often we promptly pay the price in the form of bugs reported in the field.

But, awareness is increasing in our team. I am really delighted when I see a colleague posting notes into the group-chat yelling: 

"Hey Buddy, there were no special chars in your demo.Will it work with an exclamation mark, too?"

  I love that, but I also recommend to first test the happy case using simple inputs. There is no means to attack an application with special chars if it can't even deal with the basics. Once we have convinced ourselves that the happy case works, we go over to feeding the program with more interesting input.

 It's always exciting to watch how a system deals with a combination of chars like
"{äöü},[áàâ]/|éèê|\ë!:;+(&)'%@". But, if such a test fails, developers and/or business analysts will likely give you the hairy eyeball when they see a defect documented with such example input. They probably close the issue unfixed, assuming such inputs are unrealistic and won't be seen in production.

  What has worked better for us: Use these characters in a more meaningful context so it becomes obvious to all stakeholders that the problem you spotted is worth getting fixed.

For example, we have made it a habit to use M&M's Worldstore Inc. whenever we use or create a company address. That's not because we love chocolate so much but rather because it has a mix of special characters that all caused headaches in our past and current career as a software tester: the ampersand, the apostrophe and the dot.

Same approach we apply for street-names and ZIP codes. It is a common misbelief that ZIP codes need to be numeric. Go visit the UK and check how their ZIP codes look alike. Street names can contain slashes, dashes and single quotes. Street numbers can be alphanumeric separated by a slash.

A blank in a name is not exotic. Look at Leonardo Di Caprio or Carla Del Ponte. We have seen programs that cut away the second part, leaving the famous actor with the short name "Di" or "Del".

Below find a few examples of names we regularly use in testing:

• M&M's Worldstore
• Mr. & Mrs. O'Leary
• Léonardo Di Caprio 
• Renée-Louise Silberschneider-Kärcher
• Praxisgemeinschaft D'Amico & Ägerter GmbH
  

Example street names:

• 29, Queen's Gardens
• 4711 Crandon Blvd., Appartment F#1000
• Rue du Général-Dufour 100-102
  
• 55b, Rue de l'Université 
• Elftausendjungferngässlein 12b
  

and ZIP-Codes:

• 4142 Münchenstein 1 (Switzerland)
• 33149 Key Biscayne, FL (USA)
  
• EH4 2DA Edinburgh (Scotland)
  

   Special characters are interesting wherever you can submit text.

If you post a message like "meet you at Lexington Av/59 St" and, if that text is stored/exported in an XML file without properly escaping the slash or embedding the input in a CDATA tag, you may find interesting bugs.

Backslashes are used in many programs to escape characters. Quotes and single quotes are used to terminate text elements. The latter is a common way for hackers to manipulate SQL statements so the command fired forces the back-end to reveal information not intended for the normal user. Semicolons can confuse web client logic or cause problems when information is exported to CSV files. Question marks and ampersands are both used in URL links, curly braces are common markers in REST payloads, etc. 

I personally have never really understood what is so exciting using the pangram the quick brown fox jumps over the lazy dog in testing or the filler "Lore Ipsum". Both do not contain any interesting characters. When testing German language based programs, we prefer to use  Victor jagt zwölf Boxkämpfer quer über den großen Sylter Deich because it contains umlauts and this weird ß character, although it is an unknown character in Switzerland even in the German dialect speaking area.

Most often, we use my own pangram which we have further adapted over time:

Chloë Valérie O'Loughlin-Bäcker runs the "Deacon Brodie" (Scottish Pub & Largest Whisky Collection) at Saint-Louis du Ha!Ha!, a town in Québec Canada. Her car is a Jaguar X and runs a max. of > 200 km/h. Isn't this amazingly fast?

It contains all letters of the alphabet, plus umlauts and a selection of interesting characters that challenge text processors. But, it has not helped us later find a bug in our system where an exception was thrown when the annotation text contained a capital Ü (a bug in Open Edge Progress btw.). Other umlauts were no problem and even the lowercase ü didn’t cause any harm. The system really failed only with the capital version of it. Crazy!

One of my personal treasures is the Canadian town St. Louis du Ha! Ha! This is the weirdest town-name I've ever heard of, because it has two exclamation marks. Okay, the likelihood of such a city ever being entered by our customers is close to zero. Canadian citizens living near the area of Quebec probably disagree. Testing and test input is a question of context. Westward Ho! is a town in the UK which also houses an exclamation mark.

 

Null, True, All, Test and other funny bugs related to people's names

Besides the recommendation of using special characters, it is also worth to sneak a peek at reported stories related to people's names like Jennifer Null and Rachel True. Their names were processed and misinterpreted as NULL [BBC16] or - in the case of Rachel - a boolean value [9TO5] causing a problem using her iCloud account. I have not experienced either of the two cases myself in any of my tests but we found a similar issue where submitting the search term "Alli" returned documents titled "Alligator" and "Allister". All fine, but submitting "All" ended in an exception. 

Stephen O, a Korean native living in the US had been hassled by credit card companies, because his last name was too short. When he applied the workaround by adding an extra "O" to end up with "OO", it didn't take long until he had a meeting with the government because he provided false information [NYT91].
 
Graham-Cumming could not register his name on a web-site because the hyphen was considered an invalid character [GRA10].

There is also Natalie Weiner who could not register either because here name was considered offensive [PAN18].

Yet another example is the story of William and Katie Test who were both unable to book airplane tickets simply because the system scanned the names for the term "test". A match triggered a different procedure and disallowed the process of booking tickets in production [COY17].

Wooha! That's exactly what one of my clients had implemented, too! We were surprised as there was none to ever report any issues with it. So, we investigated a little and found out, in Switzerland there are only around 50-60 people carrying the last name "Tester". Second, our investigation also revealed the system did NOT scan the last name but rather the first name for the term "test" to avoid operations executed in production; Doozy! How clever!

References:

• [BBC16]  These unlucky people have names that break computers, BBC, 2016
• [NYT91] Why, O Why, Doesn't that Name Compute, New York Times, 1991
  
• [GRA10] Your last name contains invalid characters, Blog John Graham-Cumming, 2010
• [9TO5] iCloud user locked out over coding bug related to her last name, 9TO5MAC, 2021
• [BAZ] Column "Made in USA" in Basler Zeitung by Rod Ackermann (still finding out the exact publishing date)
  
• [COY17] People’s Names That Break Websites, 2017, Chris Coyier 
• [PAN18] People with offensive lastname, Bored Panda, 2018
  

Further similar reading:

• Mein Name ist Lütkehaus, 1997, Zeit Online (need to register)
•  Names that make computers go grazy 2017, Gojko Adzic
•  Parody on a German pangram, by Tom Candussi
  

Update as of August 21, 2026:
Only today, the root cause of a failing document export was found to be in a meta-data attribute-value. It contained a TAB which was included because a user copy/pasted the text from a different source. Identifying the root cause of this failure in one affected document (out of hundreds) was only one of the challenges we were faced while investigating. 

Interpreting the Regression Test Activity Graph

We just completed a 1.5 week intensive manual regression test phase where we executed almost the complete set of all (several hundreds) test cases. We are in a lucky situation. Our documented test cases represent nearly 100% of all implemented features. If we achieve a 70-80% test coverage, then we get a real good picture of the overall quality of the product increment. That means, aside from the many automated tests, it's worth from time to time, doing some manual end-to-end regression testing.

While tracking the regression testing progress using a cloud based test case management tool, we were looking at the activity graph and it made us smile. It's exactly what we expected.

 

At the beginning, testers focus executing those test cases that are well documented, having clear instructions and which rely on previously well prepared test data. I mean, objects that are in specific states where testers can execute just the transition from one state to the next and not worry about the laborious setup steps.

 

Then, testers switch to more complex test cases which take a little more time to understand and test.  This is when the progress curve reaches the peak and progress starts to slow down.

 

Of course, we also find anomalies. Bugs can slow you down because analyzing and understanding where and when defects were introduced takes additional time. After a few days, the first bugfixes are delivered, too. Developers require your attention to test their fixes. This interrupts testers from working on their suite. The rate of passed tests is decreasing, but still decreasing in a constant and expected way.

 

In parallel, developers are working already on the next generation of the product, meaning, their user stories get shipped and require testing too. The tester's brain is now busy with a lot of context switching; clearly more than at the beginning of the sprint.

 

Now that we are more than half way through, we switch to the monster test cases. I call them like that because they do not consist of simple steps, they contain several tests expressed in tables of inputs and expected outputs. That's why I think it's nonense to talk about the number of test cases. A test case can be atomic and executed in seconds, yet another test case can keep you busy for half an hour and more.

Some of the test cases may be poorly documented and require maintenance or correction. Some test cases require the help of a domain expert. The additional information gained should be documented in the test suite, so we don't have the same questions next time. These are all activities running in parallel.

Last but not least, weekend is getting closer. The first enthusiasm is gone, you're starting to get bored.
You hear music from your neighbour. The caféteria gets louder. The sound of clinking glasses reaches your desk. It's time for a break, time to reboot your brain. TGIF! And now it's weekend time!

 

And then, Monday is back! It's time for another final boost and time to say thank you. Great progress.

 

We made it Yogi! 

 

....and I like that graph.

 

 

 

 

Simplified Bug Prioritization Matrix

No cartoon today, it is just an illustration of our internal simplified bug prioritization matrix

False Positives

When developers want to quickly demonstrate that in principle it works, they tend to hard-code things with the intention to replace that piece of code later. But, once it works, the focus is shifted to other tasks. It is likely that one forgets about these rotten code pieces.

 When Switzerland changed their tax rate from 7.6 per cent to 8 per cent, we were quite surprised that 7.6 was hard coded rather than read from a configuration file. As a result, we had to redeploy a new fix. In another example we found a code statement that made the program wait for 200 seconds. No wonder the application was slow. The developer had a good explanation why he added a wait-statement, but he mixed seconds with milliseconds.

 The term "false positives" has its roots in medical testing. A false positive is an error in which a test result improperly indicates the presence of a disease (the result is positive), when - in reality - it is not present, while a false negative is an error in which a test result improperly indicates no presence of the disease when in reality it is present.

Simply said, never trust any success messages. If the program claims it worked, the program may be wrong. Vice versa is also true. When the system throws an exception, the operation may still have worked correctly, regardless of the error.