Article summary
My vacation is coming up soon, hurrah! This means a lot of planning and booking and surfing and searching to find cool and unusual places to stay and things to do. It also usually means I find some bugs along the way which give me ideas for testing at work.
Out of Season
I was looking to take a boat trip through a canyon, but the website had a notice that the boat only operated during the summer season. However, there was no mention anywhere of when exactly the summer season was. Did it end at the end of August, halfway through September, or at the end of September? As my trip was planned for the end of September, I needed to know. I found that the website also had a Facebook page and was able to message them to find out (turns out it meant mid-September), but the experience did not create a good first impression.
Does your website or app have implicit assumptions that the user has the same knowledge you do?
Inconsistent Prices
“Boat hire–just $59 for half a day–click for details.” I click for details and see the price is listed at $55. It’s not a bait-and-switch trying to lure me in with a low price only to reveal that the actual price is higher, but it still left me confused. After contacting a couple of sites where I found inconsistencies like this, the common response was that they had updated the main page but forgotten to update all the sub-pages.
It can be hard to test for inconsistencies. Often, you might have an end-to-end test that checks that the main page displays a price, along with another end-to-end test that checks that the rental page displays a price. But there’s no test checking that the main page price matches the rental page price.
You can run a “follow the data” exploratory test where you follow the price from the server and see where it goes, or you can do this the opposite way round, following the data from the page to find its source.
Dead Links
When visiting sites to rent a boat or go ziplining, I often find a page highlighting “other attractions in the area,” but when I follow the links, many of them end up with 404s. If your page is going to link to other sites, there should be a way to regularly check for dead links so it can stay updated. For example, you might set up a link checker to run every Tuesday at 9:00 pm and mail the results to the admin.
Have you considered this as part of your site maintenance? Once the site is up and running, is the customer able to correct mistakes, or will this require a support call?
You might also think about how valuable these links are to the core business. Is the site linking to other attractions just to bulk up the content, or because all the other sites do it? Or is there another valid reason for it? Before offering a technical solution, think about what lies behind the problem and what business case supports it.
Do you manage to go on vacation without thinking of work, or does it give you ideas? Let me know in the comments–which I’ll read when I get back from my vacation!
Looking for more ways to test? Read some of the other posts in this series:
- 9 Situations to Test the Strength of Your Mobile App
- Learning from Fairy Tales
- Bugs Don’t Take Vacations
- Adding Software Tools to My Toolbelt
- Travel Bugs
- Testing Error Conditions
- Using Tea/Coffee Breaks in your Mobile Testing
- Alternating Phone Models Per Test Cycle
- Peripherals? I’d Forgotten about Those…
- A Tester’s Consistency Checklist
- “Alarming” Problems You Should be Preventing
- Quick Tests for Your Web App
- Testing for App Consistency
- Is it a Good Story?
- Quick Attacks on CRUD Apps
- Lights, Camera, Action, Bugs!
- Follow the Data