Ah, your friendly every day mug. A temporary home for your coffee, tea, hot chocolate, common enough that you may use one everyday. So why bother spending the time to consider it for testing? Other posts in this series have been inspired by interview questions I have heard people be asked. Testing a mug falls into a similar category, but I haven’t personally heard it used for interviews. It doesn’t have to be interview fodder though, it’s a domain everyone is familiar with but most likely hasn’t thought deeply about. This is makes it an interesting thought experiment, and just like software testing there is often hidden complexity or depth in areas that at first glance seem mundane.
I use a mind map to capture the results because I find these diagrams encourage the thought process. For writing, the process of using the tool doesn’t get in the way of my train of thought. For reading/consuming the information I find them extremely digestible. I’m a visual person so being able to see the surface area of the testing as a whole in a glance is really helpful. If you imagine this information structured and nested in a spread sheet I think you would find it much hard to grasp the full scope. If you haven’t tried them in your testing process, I encourage you to try them out.
What Does It Hold
A mugs primary purpose is to act as a vessel, typically for hot beverages. This is what I first started pursuing as I began thought about mug testing. I considered the obvious opportunity for cold beverages as well as hot. I even got to the point of thinking that a mug could serve as a decent analog for a bowl.
Then on a coworkers desk, I spotted a mug but this mug was not full of coffee, or tea or even soup. Pens, the mug had pens! What a revelation, mugs are designed for drinking liquids but that doesn’t mean that’s how everyone will use them.
So that may not be as dramatic a revelation for you as it as for me at that moment. It’s not that unusual, but think about your test approach. Ever been surprised to find out how a customer is actually using your software? It seemed perfectly logical and reasonable maybe even intuitive for them, but it is completely shocking to you. It’s easy to get into a rut, you can dig so deep into your own understanding of something that you can’t see outside that scope.
Core Functionality and Usability
While its fun to think outside the box about how something might be used, you don’t want to lose sight of what problem your product is trying to solve. Your mug might be the worlds best door stop, but if it’s constantly tipping over or leaking then your product is a failure.
You can’t afford to ignore the obvious. So for a mug, it needs to be able to handle hot temperatures without deforming or cracking. The handle needs to be able to support the weight of the rest of the mug and a full load. If it’s a commuter mug then it needs to be usable while driving and practically leak proof.
Just because mugs core function isn’t too flashy it doesn’t mean there isn’t a varied audience for them. People have different expectations for these products. I already covered the commuter example but extending the workplace considerations, how many people do you know in your office use their coffee mug as a minor form of self-expression.
Mugs are frequently given away, they could be promotional items with corporate logos or sports team logos emblazoned upon them or a “Worlds Greatest Boss” mug. Maybe its a collection for someone, like puzzle mugs.
In any case if your target extends beyond the utilitarian then it needs to match up to those expectations to appeal to your customers.
If you were to ask someone how would you test a mug, even to the most captive audiences the first reaction you would probably notice is some form of eye rolling. It seems silly, and it kind of is but it can turn interesting or help give you insight to some other aspect of your testing.
If you enjoyed this take a look at my other Testing the Arbitrary posts, or give it a try yourself. You might be surprised what you find…