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.


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.

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.

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++.

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.

When Testing Requires Throwing the Computer Out The Window

OK, so maybe not exactly throwing your computer out the window, but I recently saw a post on LinkedIn (here) that got me thinking about how I sometimes think and feel about testing software. The image is posted below, and we’ll do two things. First I’ll describe how I relate testing to this image. Secondly, I wanna hear you caption this photo in the comments.

3b9ea7c0-90d7-45ba-9257-3735d6c9eab2-original (1)

Throwing Your Computer Out the Window

There are a few times a week that I want to throw my computer out the window. This can be for a handful of reasons.


Sometimes it gets late in the day and a bug is still crawling around your fingertips that you just cannot catch. You know you saw it, you know that it’s a bug, and that by catching it, you might get some immediate or long term recognition for it, but you just can’t seem to reproduce it. Every time you try, there is nothing wrong, everything works, but you know what the reproducing steps are, it just won’t happen this time.

I get the same feeling anytime I have a bug that I am able repro time and again, and then I call the developer over to show them and I can’t do it. The ole “works on my machine” or “nothing ever goes wrong when you’re here, can you just stand here”. It drives me nuts when I cannot repro a bug in front of the developer.

Lastly, anytime I log in to test, and it’s just a bad day for bugs. It happens, there are days that are inevitably buggy, and I can’t get through the workflow without a bug blocking me. Then when fixed, it causes more and more bugs. This repeats itself all day until the end, when you realize how little you accomplished today, because every time you went in to test, there was a bug blocking you.


So maybe throwing the computer out the window isn’t the greatest test step in my test plan, but I say it to describe an example of testing and then losing power, or connection to the internet, or your computer just decides to blue screen. These aren’t really scenarios we test, maybe ever, but it’s always something to keep in mind when testing. What if I’m right in the middle of something and the site crashes or an unexpected error occurs. Do I have to start all over from the beginning? Did the site save any of my progress? Maybe a good alternative is to break up the workflow into segments that save on each step. This might prevent a large amount of data to be lost.

This could happen more on mobile devices when transferring between networks as you walk in and out of buildings and connect to WiFi. I wrote about this testing scenario on Mobile Testing Limitations on a Desktop Computer.

Caption Time

If you don’t have a LinkedIn account, there would be no way for you see the comments on the photo. But some of the good ones were “Troubleshooting Windows” or “Windows just crashed again”, and even “Jim put his computer to sleep”. I want to hear if you have anything better? Comment below!

Mobile Testing Emulators

It’s time to write about the research I’ve been doing to find a solution to the testing limitations of mobile testing on a desktop computer. I know that all of the issues could not be solved, but I wanted to see what we could accomplish with online software.

I think it’s important to first define the difference between Simulators and Emulators. While these two are nearly synonymous, there are slight differences that could assist in your determination to look into one product or another. Simulators imitate the appearance, design, or the basic features of a device, whereas an emulator will reproduce the features and actions of the device.

Lastly, my research was to find something that could resolve URLs locally, because we want to test our websites in lower testing environments before we release to production, so it’s important to be able to test our sites this way. That being said, let’s get started.


I’ve got to start with my favorite product that I tested with, and say the most about it. BrowserStack has it together. They offer a laundry list of devices to choose from, with different browsers to test on with each device. They have both emulators and simulators, so you can test on actual real devices, and also by simulation if the device is a bit older. You are also able to resolve URLs locally so we were able to access our sites in house. It allows automation testing using Selenium and Appium, using actual mobile devices. I didn’t look into this feature too much, I focused more on functional testing for my efforts. Lastly, it has a built in code debugger, and the ability to inspect and read the console, which is really nice for testing iOS.

A few notable items is that the trial is 30 minutes of functional testing, but this can be overcome by signing up with different email addresses once that expires. The trial only allows you to tap into a couple iOS devices, and a couple older Android devices. The trial is a little laggy and doesn’t always display the design without minor glitches, but it worked pretty well for my needs. On the plus side, they show the entire phone so it really feels like you’re testing on a device, and you get the full experience.

BrowserStack Home

The cost of the full version can add up quickly, but they do have a variety of offerings to allow you to customize to your needs. The other downside of this product (and most the others) was that the OS versions are not the most up to date, but rather uses the OS version that was released on the phone you are testing (for example, iPhone 5 uses iOS 6.0). The last downside is their screenshot tool cannot resolve URLs behind a login screen, but that’s only an issue for our type of testing.

Overall BrowserStack gets my vote.


A product of SmartBear, CrossBrowserTesting has a lot of really great features to test with. Their trial is 100 minutes of manual testing, which allows you to get a lot done to see if you want to pursue the product further, however it only allows 5 minutes at a time, so you have to be fast. Like others, their trial only allows a few Apple and Android devices, but upon payment, unlocks a ton more options. They also have a lot of devices to choose from, and many of their devices are available for testing both as real emulators and simulators. They even offer real devices as far back as iPhone 3GS and Galaxy S3, if that is a need for you.

Their trial is extremely laggy, and pretty slow to load up (which cuts into your 5 minutes), but unsure if that is just the trial or if that would be the paid version as well. Another minor downside is that their viewable area is just the screen, not the full device, but that part didn’t bother me too much, it just doesn’t give you the entire feel of using the mobile device.

They offer a great screenshot tool that allows you to quickly compare up to 25 different browsers, and they’ll even tell you design differences that they find. This tool even allows you to go behind a log in screen by passing in a username and password (though I wasn’t able to get this to work on their mobile devices, only the desktop versions).

Overall this product was great, other than it being very slow on connection, and a 5 minute trial window, this obviously has a lot of great features.


GenyMotion is a pretty cool product, and is locally installed on your computer, which in theory provides some speed increases and doesn’t fully rely on a solid web connection. This product also allows you to test things like interruptions, battery usage, network connectivity changes, and more. It actually seems to do a lot of really cool things that were not available in the above products.

However, a few things to note is that this is only for testing Android devices, there is no iOS or other available devices. Also, because it’s locally installed, you are required to have the space available and the memory requirements. It also requires some additional software, and to run against local URLs, it requires a bit of server configurations.


This was a fun product to try, because SauceLabs offers every device and every OS version to all those devices. You simply select a device, and then an available OS and get started. However, it takes a very long time to spin up the testing simulator. It appears that you can test local sites, but it doesn’t come without a lot of server/proxy work, of which I was not going to test in my short research period.

The coolest thing about this was all the available devices and OS versions, allowing you to test different scenarios and configurations.

The Others

There was another handful of products that I tried that didn’t give me what I needed or were old and outdated. These products may help in some areas, but for testing locally, or needing to test on the latest device, they didn’t step up to the plate. Or, some required money up front or further work to even try it out, of which I also wasn’t interested in my research period.

  • iPadian
    • Requires $20 to download.
  • Air iPhone
    • Old and outdated. Not even worth the time.
  • Xamarin Testflight
    • Requires in depth knowledge of Visual Studio and runs locally.
  • MobileTest.me
    • Old and outdated, does not work like I needed it to work.
  • Safari browser
    • Doesn’t work great on Windows and doesn’t do what I needed.
  • MobiOne
    • More of an App builder and tester, not for testing our sites.
  • Smartface
    • I just could not get it to install, and then was contacted by their sales team a bunch.
  • Sigos AppExperience
    • Free trial requires meeting with a sales rep. I didn’t do this, but the app looks cool.

The Winner

If you find yourself needing this type of testing software, I recommend BrowserStack. It costs some money, but will give you a lot of really great features. I was able to find a handful of bugs during my trial period as well, which was extra fun to realize the value before looking further into this product.

Mobile Testing Limitations on a Desktop Computer

When developing and testing mobile websites, there can be a handful of things to keep in mind, things that won’t be testable from a desktop computer. Although responsive design and basic functionality are testable, there is a greater list of things that need to be tested otherwise.

I have been doing some research lately for some mobile simulators and emulators so that mobile testing can be accomplished, but would not require purchasing all devices to keep them in house. That being said, let’s get into some of the testing limitations for mobile websites.

Design Limitations

There are a handful of things that cannot be tested by resizing your screen, even if using responsive design or a mobile website. Some of these might be intended, but most just need to be considered when developing or testing.

Hover affect

The hover affect is often used when designing desktop applications or websites, yet completely (almost) unavailable for use when designing a mobile app or website. Keep this in mind and do not allow crucial information to be hidden behind a hover affect.

A couple examples of a hover affect would be a button or link, as well as popups or tooltips. Images also contain hover affects sometimes, such as zoom features or even informational text about the image. Be sure to test alternative options for these things if they contain information that the user needs.

Hidden pages

Sometimes there is a need for pages to be hidden when working in a mobile view. This can be because the functionality is too difficult or time consuming to develop on mobile, or because it’s not an on-the-go page that will be visited. Always be aware of these pages however, if there is a difference between hiding from the user’s view and the page should be inaccessible for the user. If the latter, be sure to test entering the URL directly, and ensure the page doesn’t load or that some type of message displays.

I’ve been asked why we should worry about users entering URLs directly, as this requires them to know extensions beyond the basic .com. I usually give these questioners the basic answers like, an email contains the link, or, people may have favorites set up and shared between devices (more prevalent with Chrome and Android devices), but really, the reason is more around business requirements and expectations, or simply going above and beyond our responsibility as a tester.

Business decided features

Similar to the above approach, sometimes individual features should be hidden from the mobile user, due to restrictions on functionality, security reasons, a product manager’s decision, and others. This functionality is usually pretty easy to test responsively by resizing your screen, and the only details to note are the break points. At what pixel resolution should these features be hidden.

However, some companies like to design their mobile websites with a device detection and then rerouting to a mobile site. If this is the case, you might be able to test this on a desktop computer by navigating to the URL, but be sure to test the mobile rerouting on a device, as that cannot be tested otherwise.

Just be sure that if there are features that are not supposed to show on a mobile device, that they don’t.

Pinch zooming

Mobile pinch zooming is something that can be slightly tested using a desktop computer, simply by scrolling (zooming) in and out of the page. However, testing this way may not be sufficient, as this is not how mobile devices render their screens on pinch zoom.

Imagine the pinch zoom like the Microsoft Magnifier tool. It simply zooms in on the screen instead of restructuring the pixel density. So when testing zoom, be sure your site doesn’t realign objects, or if it does, that it’s purposeful.

Fingertip density

An important thing to test is how objects appear on a mobile device, and if it is too small for use. This is especially important for buttons, or anything that requires a click, as the standard fingertip is a quarter-inch or more. No need for frustration due to fat-fingering, just be sure the buttons are big enough to click on.

Device Limitations

There are also some things that are much more difficult to test without using an actual physical device. Though some might be somewhat testable with an emulator, there is nothing like testing on the device itself.

Slide outs or dragging

A lot of sites have side navs or other features that are accessible by sliding out from the side, or by dragging objects on the screen. Trello, for example, does a great job of utilizing their drag and drop feature on the cards, with the ability to drag to the side causing the page to scroll. Be sure to test this with respect to the device’s ownership over certain dragging motions such as the drag down from top or up from the bottom showing the phone’s menu. Or on an iPhone, if you drag from the left, it pulls up the app switcher tool.

Excessive battery use

Something that is nearly impossible to test on a desktop computer is how much battery your app or website will use. Depending on the user of your site, this may not matter, but don’t discount the battery hog that a site could be, especially when doing things like reporting or building documents.


Interruptions happen all the time when working, and this is no different when using your mobile device. Some interruptions aren’t as bad, such as a text that can be ignored. But there are other notifications that take over the whole screen, like a phone call, that if accepted or ignored, should return you to your site. However, based on the security of the site you’re testing, you may consider any interruption a reason to log the user out. Always consider interruptions when testing, such as locking the device, answering a call or text, or merely switching applications to check the date on your calendar.

Network traffic changes

It’s happened to all of us, we are working on something on WiFi, then we walk outside with our phone and it switches from WiFi to LTE. How does the device handle this switch, and how do we even test this? If this is a concern for your site or app, then be sure to walk around while testing. Go to the elevator, the concrete stairs, or even for a walk outside. Be sure your site handles this switch as expected and no errors are thrown on network changes.

There are a handful of other limitations to testing mobile sites on a desktop computer, so be sure to think through these when testing, and go above and beyond the testing effort next time. It’s sure to pay off for your end users.