On Site Appointment Booking Application Testing


Currently I am challenged with testing an online appointment booking app that uses Google maps API to validate addresses that are entered into a search window. Once an appointment is booked we deploy a service associate to the specified location. We have constraints in place that only allow specific areas (4 cities to start) to be bookable and we also have placed restrictions on the types of addresses we allow to be booked. Specifically I think we filter to the following from the supported types that Googles API provides (https://developers.google.com/places/supported_types)

  • street address
  • premise
  • subpremise
  • establishment
  • route

I just need ideas on how I can effectively test this application to ensure clients within the supported areas are able to successfully book an appointment. Some examples of test cases I have run so far are as follows:

  • addresses outside of the supported area
  • addresses within the supported area
  • addresses that contain unit numbers
  • addresses that have not yet been registered (new neighborhoods)

If anyone has tested a similar service before and has some advice on how to approach this challenge it would be greatly appreciated.


1 Like

What are your area criteria/constraints? Can you specify geofences? Or is it based on municipal or postcode boundaries. Depending on these , you want to be clear to management whether you are “testing” the google API, or testing our understanding of what the API responds with how closely it is corresponding to their service area map. Which is probably not the test they think it is. The only useful cases in my mind are how the UI journey works for badly entered addresses, and for new addresses, and then of course what happens when a user is not inside the zone as a partition test case.

Hope you get more useful inputs as the day goes on though.

It’s based on municipal boundaries right now with the hopes of using geofencing in the future. The only constraints are the service can only be booked within the boundaries of the municipalities and need to be actual addresses (with postal codes). The idea being customers should not be able to book a service call on the side of a highway or in the middle of a national park just to name a couple of examples.

It turned out that the majority of issues discovered were badly entered addresses. That was the hardest part of testing this application. Given a customer enters an invalid address, that we appropriately message that the address is incorrect. Problem is, it seems there are endless ways to enter an invalid address and it was a game of discovering all the permutations that could possibly be entered. Not sure I came out of this experience with a solid understanding of how to test applications like this, but it was a fun exercise none the less.

Thanks for your input Conrad. It did help to hear others opinion on the test approach.


1 Like

Wow, who would have thought that validation rules for addresses are so hard. I mean in the UK, postcodes can be validated using an actual real web service. You pay someone, per call, and they give you the answer, it’s probably simple if you have budget. But the non 3rd party solution really lies in communicating with someone in the postal service who can hopefully validate many of one’s assumptions.

Not sure why this reply is on top of my feed today Andrew, but your sharing about how difficult it was to test, is going to help me in future too. I had assumed it would be solved with a load of math, more than a load of rules.