The quirky little bug that taught me a valuable testing lesson

The (not so) good old days 

Back in 2003, when I was a fledgling Junior Quality Assurance Associate, I was just starting out on my testing career. Starting late, I became a tester at the ripe old age of 37. I can tell you that the tech wasn’t quite what it is today. We were still 4 years away from the smartphone revolution, which spoiled my ‘pretending to be Star Trek Enterprise crew’ by flipping my phone open. Nokia phones existed which had batteries that lasted weeks, if not months. The cloud was what you saw when you looked out the window, and data lakes occurred when someone dropped a binder in a stream. 

While I remember those days fondly, frustratingly, and in other ways depending on the memory, you are not here for my reminiscences. You are here to read about a tiny bug that made me think differently. We will get to that, but you need some essential context. 

Banks don’t move fast when it comes to technology, although it is a bit better these days. Parts of the bank's systems were on monochrome screens. For those of you too young to get that reference, it was essentially a black screen with green text or basic form outlines. Our high-tech Windows 2000 or XP machines, which took up to 25 minutes to boot, were used to display a rectangular grey frame displaying mortgage and loan information. There were many sections that did everything from capturing home and correspondence addresses, to running direct debit requests and more. They all came together to manage mortgages and loans from all over the country. We were a third-party support entity, and multiple banks and building societies used our systems. 

Assessing the ordinary 

A new screen to test 

My job was to test updates, changes, and new screens in a banking and mortgage management system. The system was old, built on layers of legacy code. Even simple screens had the potential for odd or surprising behaviour. It is on one new screen in particular that this story will focus on. First of all, you need to understand that I was a very new tester. And secondly, that there was nothing remarkable about this screen. While it was new, it didn’t have groundbreaking new capabilities. It was just a typical, simple run of the mill data capture form. The data it captured wasn’t really new either. But we are only really interested in one field. The postcode. 

Even postcode fields can be fun 

I know what you are thinking (I think). Despite my warnings that this is about old technology, you were hoping for something exciting, funky or much more interesting. Well, here we are. 

“So, at least it is about all the weird and wonderful things you can put into postcode fields?” you ask. You mean things like: 

• All letters or numbers 
• Upper and lower case letters 
• Well-known postcodes like SW1A 1AA for Buckingham Palace, London (the King's house) 
• Funny ones like H0H H0H for Santa Claus, North Pole (in Canada) 
• 0 (number) or O (letter) as used in the UAE or Hong Kong 
• 123 for Iceland (the country, not the frozen food shop in the UK) 
• Security hacks like <script>alert(1)</script> a classic cross-site scripting injection (p.s., if you use it for real, you didn’t get it from me, ok) 
• All the 9s, a space, blank, NULL, or gibberish 1h1k11o23k43nrb5hjkf9vfnf

Sorry, no, but they are fun and interesting to try. Also, they wouldn’t find the bug I found. 

The bug (sorry if it is not what you were hoping for)

I don’t know if it would even be relevant today, I suspect it is, but very rare if it occurs. But it did make me think differently about filling in fields. And it was so odd that my quirky little bug find ended in a whole system review to look for more. So, without further ado, the bug. 

Postcode 

Postcode

Before you read on, take a second and really think about what you are seeing. The same field, but with different inputs. Got it? Not got it? Read on when you are ready. 

Once again, I think I know what you are thinking. ‘What???’ That’s it? Indeed, yes. That is the bug I found. Honest and truly. The postcode field allowed you to enter 56 lowercase letter ‘i’. But, it only allowed 13 capital ‘W’. 

If you spotted the bug before I explained it, congratulations. It took me an embarrassingly long time. It was a long time ago, and memory can exaggerate, but I think what is now remembered as hours was probably more like 20 to 30 minutes. 

The explanation 

Why the field behaved differently

Have you worked out the why yet? Don’t worry if not, I’ll explain. I eventually worked out that I was missing the difference between the UI and the data constraints. I had assumptions going in, and that was a lesson taken from that day. 

The text entered was determined by the field's length on the screen. Now, I may have been new, but I knew that databases had limits and restrictions. I also knew that our practice was to set the text length based on the data requirement. So in the UK, a postcode has up to 8 characters, a mix of letters and numbers, and is between 5 and 8 characters long. For example, AB12 11BA, A1 1AA etc. From previous experience of similar fields on the system, I could have reasonably expected to enter 10 characters at most, but definitely not 56! 

The fall out 

I raised a ticket. In those days, I was once taken into an office and told off for, and I quote, “wasting a developer's valuable time”. So I couldn’t just walk over and have a chat. Questions were raised, risks were discussed, and brows furrowed. I had almost no input into this part, being a lowly test body. In fact, the only real details I heard were that a review of field settings was done to ‘catch’ any more that had been done that way. I did get an excellent review that quarter, so in the end, I was happy. 

To conclude

To this day, despite having found many risks, issues, and bugs, this is still my favourite bug. Partly because it was early in my career. Partly because it was the first time I was really recognised for finding a bug. But mainly, I think, because it made me think differently about forms and, in a smaller way, testing. Those assumptions I was making going into a testing session were holding me back. I needed to become better at recognising them, questioning them, and thinking more deeply in general. Even if what I was doing or testing seemed ordinary and basic. 

It took me a while to work out what was going on. I knew what the form should do. I had some requirements and was aware of some best practices. But making the connection between what was happening and what I was seeing took a leap of thinking. I learned about visual length that day, but even more, I learned that making assumptions about what I see can be unhelpful. That information helped me find more fun bugs related to leading, middle, and trailing spaces. But that is a tale for another day.

Thanks for reading.