Break Your App With This One Weird Trick

I missed a bug recently, more than once, and I’m kicking myself about it.  This post is about that bug and how you should make sure to always run a test for it. It’s also about how to keep from repeating your mistakes.

Here’s what happened: as I mentioned in a previous post, I’m currently testing file uploads and downloads.  When the developers on my team first coded the upload functionality, I dutifully tested all kinds of file names: long names, short names, names without extensions, names with capital letters, etc.  Everything looked great, but I missed one important test: testing file names with spaces.  Every file name I had tested with was one single word, like “sunrise.jpg”.  I forgot to test with a name like “Grand Canyon.jpg”, and as it turned out, uploads with spaces in them weren’t working correctly.

Spaces are SO easy to forget to test, because they are literally invisible!  Testing with spaces applies to any text fields, not just file names.  For example, when you are testing a first name field, make sure to test with two first names, like “Mary Jo”.

It’s also important to remember to test with a space at the beginning of the text and at the end of the text.  Your developer should be trimming these whitespaces when processing input, but if he or she forgets, this can mean trouble.  You may wind up with a situation where you have a list of names sorted by last name, and the name “Smith” is appearing at the top.  This is probably because someone entered ” Smith” with a leading space.

Similarly, your users might have problems logging in to your application, even though they are sure they have the right username.  This may be because when they set their username, they accidentally put a space at the end of the username, and that space was not trimmed by the developer.  So they are trying to log in with “catLover” when they should really be logging in with “catLover “.

Back to my story: after the bug with file uploads was discovered and fixed, I carefully retested uploads again, this time being sure to include file names with spaces in the beginning, middle, and end of the file.

Our next development task was to be able to resize a file upon request.  When this functionality was ready, I started running all kinds of tests: resizing by height only, width only, height and width, resizing various file types, etc.  While I was testing, the developer who worked on the feature mentioned that he had just discovered a bug: the files wouldn’t resize if they had spaces in the names, because the spaces weren’t being encoded properly.  I’d like to think I would have discovered this eventually, but who knows?  I was more focused on the new functionality than I was on regression testing.

The bug was fixed, and again I carefully tested it.  I added spaces in the beginning, middle, and end of the file name, and I used every kind of special character on my keyboard.  Surely, I thought, this must be the end of this bug.

Our next development task was to do file size and type checking.  We didn’t want to upload a file if it was larger than the application was told to expect, or if it had the wrong file type.  I tested with files with all kinds of sizes and types, and all kinds of mismatches.  With each mismatch, I verified that the file was checked and rejected.  I did a great deal of regression testing as well.  It occurred to me to test with different file names, but since this I had already verified that file names of all kinds were working with resizing, it seemed like overkill, so I chose not to do it.

I was wrong!  As it turned out, the system that was doing the file checking was different from the system that was doing the file resizing, and once again, spaces in the file name weren’t being encoded properly.  A developer noticed that every file that had spaces in the name wasn’t being checked by the system.  I was bitten by the file space bug once again.

I hate making mistakes, and I hate missing bugs!  Fortunately these bugs were caught before they impacted any end users.  But I like to learn from my mistakes, and I’ve taken the following steps to make sure I don’t miss this bug ever again:

  • I’ve put a sticky note that says “Spaces” on my desk.  Whenever I see it, I will be reminded to test for spaces in my inputs.  I did this years ago when I kept forgetting to test on different browsers.  I had a “Test on IE” note on my monitor, and it helped me develop the habit.
  • I’ve added file names with spaces to my saved Postman collections.  This way, even if I forget to test with spaces, the saved requests will remember for me.
  • I’ve written this blog post to serve as a cautionary tale to myself and others.
One final lesson I’ve learned from this is that different parts of the same feature can process information differently.  The feature is using new technologies that I’ve never tested before, and I assumed file names would be handled in the same way for uploads, resizes, and type checking. But that was not the case.  When you are dealing with new technologies, be sure to regression test everything, even things you think might not need to be covered.
It’s amazing how much one simple space can break!  When you are testing anything that can accept text, from a simple form field to a file upload, be sure to remember those invisible spaces.

8 thoughts on “Break Your App With This One Weird Trick

  1. Mark Turner

    Remember, quality assurance is to assure you have found no bugs in the amount of time you had for testing. I would be amazed if I have caught every bug in my product. With agile, the chances of bugs occurring will increase as the product is constantly evolving, that is why there is a fix fast idea which comes with agile. That is why ideally you build an automated test for everything that is required for a user to perform the operations which will stop them using a competitor.

    Also quality is a team responsibility. Why was it not picked up in the code review or initially by the coder? So don’t be so hard on yourself.

  2. Kristin Jackvony

    Excellent points, Mark! The bug was actually discovered by the coder each time. The first and third time it was discovered by the dev through monitoring the application, and the second time the dev discovered it through testing. I work with awesome devs who really care about the quality of their product. I know I can't always find every bug, but I'm constantly striving to improve my processes. πŸ™‚

  3. Chrissi

    Great post! I have notes saying "Spaces" and "Apostrophes" – lost count long ago of the number of times an apostrophe in a name caused a problem so Mary Jane O'Connor is now part of my test armoury.

Comments are closed.