Testing The Rare Occurrences

Sometimes when testing, we encounter scenarios that are so rare that they may only happen once or so a year, every few years, or perhaps only once in a lifetime. These types of events or occurrences need to be in the back of our mind while they are approaching, so we can be sure to test when necessary.

The Daylight Savings

While not every town in America recognizes daylight savings, and especially the whole world, it is a strangely impactful event that really messes some people up in Spring, and one that some looks forward to in Fall. Most go to bed at night wondering if their alarms or phones will auto adjust for the new time come 2:00am, and there are some like myself who set multiple different alarms on different devices to prevent waking up late to the Sunday morning activities. The latter of course being a Spring problem.

When testing, it’s important to note if your product has time as an important factor, and if so, what happens when the clock strikes 2:00?

I thought it was interesting when I checked the weather for tomorrow’s day and noticed 1:00am written twice. That actually took me a moment to process and then made entire sense as we will relive the 1:00-2:00 hour tonight.

Seeing this made me think of the testers over at The Weather Channel app team, and the scenario they had to test which occurs twice a year for only specific regions of the world.

The Leap Year

I recall a few years back encountering a production bug with a user’s data who had February 29th as part of their information. Though I don’t recall exactly what field, it unfortunately wasn’t an obvious field like birth date, but rather something like CreateDate or an audit field which caused the user’s login page to look a little funny. This led to deeper investigation with a temporary fix of moving the date to something more regular until we were able to push a more permanent fix to production.

This would be another scenario where testing is so rarely encountered, but something noteworthy when the time approaches.

The Others

A couple other events to consider when testing is phone numbers and license plates. Recently I wrote about the increase in character count on the license plates in Wisconsin. That impacts things like the database and the UI that the DMV uses for license plate renewal and registration. It also has an impact on the software that car dealers use when distributing new plates. It is possible that any software was designed with this in mind, but testing and validation becomes slightly different, as now they accept letters before numbers, and vice versa.

I was recently thinking about phone numbers and how the seven digit numbers are soon to max out with the distribution of phone numbers growing so fast. They were able to assist the problem slightly with the introduction of area codes, but the problem will reiterate itself again soon I’m sure. Of course they can separate regions and add more area codes, but I wonder if and when they may add a region code like they did a few years back when people used to type 1 before the area code.

While I don’t know much about the phone number industry, it’s just another one of those events that occur so rarely that it may never be tested or designed originally, but perhaps the kind of thing we as testers should be aware of if the time is approaching soon.

Fortunately we are still a long way off from a five digit year!

What other rare occurrences have happened in the past or are yet approaching that we as testers have had or will get the joy of testing in our lifetimes?

The Importance of Clear Text

Took my wife out to dinner and while looking through the menu, we noticed a whole bunch of typos on the restaurant menu. I don’t recall seeing any spelling errors, but there were double commas, single and double spacing between ingredient listings, written out numbers like three but also condensed like 2, etc.

The Tech Writer

At Zywave, we have a technical writing department that ensures accuracy and consistency of on-screen text and our help materials. I actually began my career at Zywave as a tech writer and learned so much from the position. At times it may seem like a tedious job, or some outside the department may even have thoughts of its purpose, but I recognize the incredible value they provide. So often people can forget how important the consistency of text can be and the damage it could have on the users’ workflow if there are a lot of mistakes.

Last night I found myself searching the menu attempting to find yet another typo, that I wasn’t actually reading the menu searching for what I wanted to eat. I was so distracted that I had to continue the distraction further, and therefore not accomplish the task.

At one point, my wife said to me “restaurants should just hire us to proofread their menus”, to which I responded “they could bring us in, provide us a free meal, and we just analyze the menu throughout our meal”.

The restaurant we went to was not the first with menu mistakes. In fact, it may not be surprising to hear that nearly every restaurant we visit, we find a typo somewhere in the menu. Perhaps these menus are proofread before printing, but likely not by trained professionals that look for issues and correct them every day. Our human eyes are naturally drawn to mistakes, which is why we see it in human behavior before we recognize anything normal. This tendency easily distracts us from the workflow we’re in, so it’s important to have clear concise text.

Being a good QA tester is not just finding the bugs in functionality, it’s being a fully developed, well rounded analytical thinker who can evaluate all aspects of the product, including text and design, and ensure accuracy and consistency across the product. Training our minds to look for all these things can make us stand out in our work performance, while also having a positive impact on product output.

Next time you’re at a restaurant, see if you can find a mistake, I almost guarantee you will if you look hard enough. Also, here is a comic just for fun, not entirely related, but perhaps what some think the Tech Writer position is about.

Related image

Disclaimer: I have no tech writer review my writing, so it’s entirely ironic and accidental if there is a typo in the above piece.

When I Beat the Chess Master

I love board games. I really enjoy strategic board games that aren’t much over two hours. More serious gamers would scoff at this and tell me that I am not really into strategy games if I don’t enjoy games over two hours, but nonetheless, this is me.

I beat a friend of mine at chess, best two out of three games. Despite coming into this experience having already loss one game to him, I was able to pull out two victories over his single. Technically we are tied overall, but in that sitting, I walked home with the victory.

What does this have anything to do with anything?

The personal reason that I write about this moment in my life is to not forget when I beat my friend at chess. He is not actually a chess master, but he is good, plays way more often than I do, and claims to have never lost to a human. The joy of winning filled my spirit so much, that I had to hold back my smiles that day so as to not appear too happy, so that others would not ask why I am smiling so big.


However, there is an indirect relationship between testing and playing a game like chess. Chess requires you to think of multiple different scenarios all at the same time. It requires you to know your opponent like knowing the users of your product. Chess requires you to think a few moves ahead, while determining the bad things that can happen because of that move.

Much like testing, chess requires you to think analytically and critically of the situation. It’s important that you analyze all the options, and when you make a mistake, you will end up feeling that hurt later down the road.

The moves of a particular piece in chess is also important. You must know what each piece does, how it moves, defends, and attacks. Similar to chess, testing software has moves that are necessary to make, in order to discover other avenues, other scenarios. Sometimes you have to sacrifice one piece in order to test another scenario.

Additionally, the pieces have innate value that are both relative to the situation, and preferential to the player, that can be directly related to positions at a software company. There are people on my team that have to march forward in certain ways to build and protect the authenticity of our software. Others have to jump around to get things to happen the way they want or need. Some might have the ability to move long distances and have great affect, but only in very particular ways, while yet another has the power to move nearly anywhere, in any direction. Much like the pieces of chess, these players are all valuable, and are required at different moments throughout the development process.

Playing any game like chess, can help make the mind more analytical. I am no chess master, and would still say my friend is better than I, at chess. But because of my analytical thought process, I was able to evaluate situations, and come to conclusions with my pieces; essentially testing the game before moving.

I may never play him again, because you’re only as good as your last game. But I will certainly revel in my victory until the next inevitable loss arrives.

And just in case he reads this, I also destroyed him at Othello one time after he described his current victorious streak. I may write about that sometime too.

And So It Begins

Well, I finally bought a URL to further identify my name. I have been debating purchasing because it meant a few things. First, it means that I am out an entire $48. Second, it means that I should probably post regularly so that the identification is worth it, and continue making the name known. Lastly, it could add some credibility or validity to what I’m saying, though I’m not sure it always should.

The Journey


If you’ve read my original post when I began to write, you might remember that I have wanted to write a blog for a few years. You may also remember where my QA Blog journey officially began earlier this year. It started as a goal for myself, as part of my career development. I wanted to be more engaged with the QA community, and I also want to be a teacher/mentor of the QA role, training people to be more analytical, to think outside the box, and to test like they’ve never tested before.

These desires led me to start writing a blog online. I had no expectations of followers, or active readers, or really anything like that, but to fulfill a career goal, I needed to be somewhat active with my writing. Once I got a decent amount of pieces written to make it worth mentioning my blog to people, I figured it was time to make it real by purchasing a URL.

The Choices

I came up with a few different ones and tossed them around in my head while also presenting them to some friends and co-workers. I wanted to be sure that whatever I bought, I would be happy with for an extended period of time, which right now is just year to year. A few of my ideas were:

  • qaingtheworld.com
  • testingtheworld.com
  • lifeofatester.com
  • qalife.com (although taken, there is no real site)
  • mckelveytesting.com

I heard back from some people, and it was pretty much an equal consensus, they all liked lifeofatester.com. This was originally my second favorite option right after qaingtheworld, but I assumed that URL was a lot harder to read and say to people, so it quickly became a secondary option.

The Questions

I have had a few people ask me some questions about what is next, what do I want this to look like over the next few months or years, and my answer right now is simply, I don’t know. I have dreams of certain things happening in my career, but right now I’m just going to continue expanding my knowledge of the QA life, try to become even more analytical, and take that where I can in my future.

Three SQL Server Management Tips

It’s funny how you can go so long without hearing a particular word, looking up a phrase, or asking someone how to do something, and then back to back, things all come up at once. This happened to me with SQL Server Management Studio. Three times over the last couple days, I was able to share a tip with someone to assist them in their day to day.

Removing a Server Name Connection String

Over time, it’s bound to happen, you have to update a connection string so that the database can continue to evolve. This can cause your Server name list to get bigger and full of useless disconnected servers. Here’s how to remove old names:

  1. Open SQL Server Management Studio > Click File > Connect Object Explorer…
  2. On the Connect to Server pop up > Click the Server name: drop down.
  3. Hover over the connection string that you want to remove and press DEL on your keyboard.
  4. Repeat for any desired names listed.

Color-coding Your Database Servers

This is an easy-to-find option to add to your connection server, yet most don’t know it exists. I find it useful to color-code my environment-specific databases so I know immediately where I am when querying.

SQL color

To do this:

  1. Open SQL Server Management Studio > Click File > Connect Object Explorer…
  2. On the Connect to Server pop up > Click the Server name: drop down and select the desired Server that you want to color.
  3. Click Options >>.
  4. Check the box near the bottom for Use custom color:
  5. Select your color and click Connect.

Multi-Line Highlighting

This nifty tip comes in handy for two reasons. Any time you want to add to or edit a bunch of lines at once, or, if you’re like me and need everything to look the same by updating all “Select” to “SELECT”. This also works in most coding tools like Visual Studio, Notepad++, and others.

MultiLine  >>  Selects

To do this:

  1. Hold down ALT.
  2. Click and hold where you want to begin dragging.
  3. Drag vertically and left or right.
  4. Type some characters and notice they type the same in every line.

You can also copy/paste vertically as well, which has proven very efficient if you need to copy code from one place to another.

The QA Benefit

So how does this relate to a tester other than being slightly particular about how our queries look? Learning these types of tips allows us to be more efficient getting more done in shorter amounts of time. It also assists when we see our developers manually typing the same thing over and over again in eight lines of code (actually happened). Lastly, if you’re a QA Engineer, this can be especially helpful if you need to change a bunch of lines of ASSERT statements at the same time.

There is no shortage of tips for different products, from hot keys to UI button placement. Perhaps there is a way to consider adding some tips into your daily testing to make you more efficient.


*One more for those who care. I always use CTRL+C > CTRL+V when your cursor is at the end of a line of code and you want to copy the entire line. It saves you time of having to highlight the entire row first. CTRL+D also works in Notepad++.

Don’t Send the Test Emails in Prod

I was recently scanning through the Messages on my Qdoba app and saw one of the messages at bottom was a test email. It was titled test and the subject was test. This got me thinking about how we test and when it’s especially important to be careful.


It seems like an easy concept… don’t add test data to production that the customers might be able to see, but in practice, this may not always be the easiest thing to remember. There are a lot of testers and lots of testing, any one of them could add data to prod.

The first is functional testing. As a functional tester myself, when I’m in a testing environment I will add fake data all day. I’ll add some names, run some reports, and importantly, ensure all emails work correctly. Sometimes you may have to test sending an email to all of your clients at one time, but this test email should never be sent in prod, so be sure that your data is set up so that if it requires a test, you send with an actual email ready for your clients.

Secondly, there can be a lot of service testing or automation testing that could run and accidentally send that test email. In a lower environment, we’ll have tests running all the time to ensure things are working. However, it’s important that these tests either don’t run in production, or if they do, that again they use real data that is OK for the clients to see.

Whenever you test, be sure to future-proof everything so that your customers don’t randomly get a test email that you can’t undo. It looks bad, causes confusion, and may even turn into a day of customer support phone calls that no one wants to deal with.

It’s not a hard concept to test, but in practice we need to always remember the importance of production data.

Finding Bugs is the Cool Thing to Do

I was presenting in a meeting and a handful of times, I said something like “I was able to find this bug and it was really cool” or “it was cool when I found this”. In a laughing manner, someone attending the meeting asked one of my developers if it was cool to them that I found those bugs. Part of me felt bad while the other laughed along with the crowd.

Spider Squashing

If you’re like me, then you believe that spiders are literally hell on earth. There are few bugs (in southeastern Wisconsin) that compare to the spider, especially those big black ones with thick legs, strutting around your house waiting to attack you while you sleep. After screaming like a girl, there is nothing more satisfying than taking a giant boot and obliterating that spider and all its worth. It feels so good and reminds me of the man that I am, that I protected my family from the evil Dr. Spider.


Software Bug Squashing

Finding a bug may never be a cool thing to a developer. It may point out their failure, or an area that they didn’t think of. Some bugs are so obvious that they should have never gotten past the gatekeeper, and over to us in QA. But it happens. As a QA analyst, finding the bug is very cool. Not that we like pointing out failures in others or anything, but rather as a team, we are working together to make the best product available. Finding and fixing any bug is actually an accomplishment because it means our users will not find the bug, or be bothered by it’s existence. They will not see the bug crawling around in production and scream like a girl when they see it. How is this not a cool thing?

Additionally, I am merely giving my developers an opportunity to be the big dawg on campus by obliterating the bug and becoming my rescuer, although they don’t seem to agree how cool it is that I found the bug.

So maybe it’s not COOL, but it is beneficial, and for that, there is no sorrow in finding and reporting a bug.