Bug or Intended Functionality?

Today I was taking advantage of a deal to get free cheesecake as long as I used this newer restaurant order and delivery service. The delivery service was offering free delivery today, I’d assume to acquire new customers, and offering a piece of cheesecake from a local restaurant at the same time. However, there was one contingency. The order had to be placed today, December 6th, and the order had to be delivered/completed on December 6th. While that seems like an acceptable rule, there were some issues.

First thing to note, this site allows for future ordering as well, and then will place the order and deliver on a chosen future date. I’m not sure if I personally would ever use this feature, ordering my meal online today, but not wanting it for two or three days, but I am able to recognize the value for people that may want to get all the meal details figured out before hand, and then spend the remaining few days preparing their house for the guests.

Now that we know that information, when I went in to order my cheesecake, it presented me with the next available earliest delivery time, two days from today, around 11:30am. This wasn’t going to work, as I needed to close my deal today in order for it to be free. I searched for the ability to change delivery to today, but it did not appear to be an option, and finding the date/time selector was no where near my shopping cart. Additionally, I wasn’t even sure how to check out, because everything was disabled. I eventually found the time selector where it informed me that today’s times were already full, and I must select a time two days from now. At this point I figured out that I could select a time two days from now, and that I would just go to the checkout page and enter the code, to see if it would still work.

After choosing two days from now, around noon, the checkout button became enabled. On the checkout page, I entered the code, and the cost of the cheesecake came right off the total bill. There was also a Change button next to the Date/Time of delivery. I clicked that and was able to select today’s date for 12:30pm. Submitted the order, and sure enough, my cheesecake was delivered right on time.

Bug

So what’s the point of this story? Why do I write about my cheesecake experience today in an overall negative tone, while still expressing the positive outcome of the day?

Most of what I write is to train our minds to be more analytical, to think about our processes and workflows, and evaluate how it went, while possibly considering better ways to do it. With all the websites out there that have a workflow in order to get something done, it just means there are a lot of opportunities for improvement.

I don’t need to go into detail of each area of improvement I would recommend for this restaurant order and delivery site, because often times enhancement requests and user workflow is different for every person, and also because if you’re reading this, you can spend a moment thinking of how to better the experience. As a QA tester, we have an opportunity to speak up during the building process and ensure that the workflow is the best it can be for the user. It doesn’t mean we will always be heard, or that as a team we will build the best user workflow, but it’s important to recognize the value of the team, and how each person looks differently at the workflow.

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.

chess-e1508192259578.jpg

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

sailboat-37725_640

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.

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.

Qdoba

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.

bugs

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.