After finishing the interpretation exercise I was curious about the next exercise. It’s called modeling. This sounds for me a bit more practical. The briefing said, „Modeling software under test helps to analyze it, learn about it from different angles to be able to find useful test ideas." Touring is one way to explore different perspectives of an application. Michael Kelly provides a well-used set of tours: FCC CUTS VIDS (Feature-, Complexity-, Claims-, Configuration-, User-, Testability-, Scenario-, Variability-, Interoperability-, Data- and Structure tours). This exercise focuses on the Configuration, User and Data tours.
The exercise is to “apply the following tours to Google Calendar. Take 5 minutes for each tour”.
- User tour (instead of five users, do this for one: yourself)
- Data tour
- Configuration tour
My results for the tours are:
- Adding appointments and reminders
- Synchronization with other devices (mobile)
- Display public holidays in the calendar
- Printable version of day, week and month
- Google Maps navigation to appointment
- Showing the website of an appointment location
- Categorization and prioritization of appointments
- Create recurring meetings
- Importing/exporting calendars
- Create new calendar
- Add contacts
- Add calendar from other persons
- Display Density
- Time zone
- Date format
- Time format
- Import Birthdays from Google+
- Show bank holiday and calendar week
- Hide morning and night
- Automatically declining events
- Who’s my one on one with
The data tour was the most difficult for me. I was not sure what exactly the major data elements could be. I put together some thoughts on my own, then I discussed them with my mentors Alex and Thomas. There were some points we agreed on, and some where our ideas differed. Alex gave me the hint that I should watch out for “CRUD” (Create Read Update Delete) to find data elements. Additionally, the three of us worked on the following breakdown to understand and classify the data elements.
|Attributes||Data elements||Data objects|
Looking at the data in this way helped me to understand the tour better.
Once the exercise was done, it was time for the evaluation.
1. For each tour write down 3 things you would want to test.
- Is the application saving the appointments correctly (with the chosen date and time, in the chosen category and priority, with the given name and in the chosen calendar) from the user’s point of view? (i.e. testing how this is presented to the user in the UI).
- Do the reminders work as they should? (At the chosen time and in the chosen way e.g. via SMS)
- If you synchronize the calendar with other devices, will your calendar elements synchronize correctly (like they were before at your application)?
- For the appointments there is an interference with the User tour, so I won’t list them again here.
- Is the application saving the tasks correctly? (With the chosen “due date”, the given description and in the correct order)
- Does the feature “sort by due date” work correctly? What happens with tasks that don’t have a due date?
- What happens if you save an empty task (or one with just with a blank name)?
- Does the hide/unhide function work?
- Is it possible to change settings and save them? Are they still changed when you logout and login again?
- In a multi-calendar context, are elements assigned to the calendar which was picked?
- Are data from other Google services imported correctly? E.g. Birthdays from Google+
- Are the changed settings still modified if you logout and login again, change the user or the device?
2. How did these tours help you to come up with different test ideas?
- Similar to the first exercise (interpretation) the tour helps to focus on parts from the application where errors may occur that are particularly painful or critical for a user.
- The user tour in particular gives the tester an idea of what’s important for the user and may help to guide risk-based testing.
- Simply by using the application to gather test ideas means that the tester familiarizes themselves with the application, which helps to generate even more ideas.
- Since specifications are likely to be ambiguous or perhaps not very detailed, it makes sense to do tours of the application to see how the test object behaves and compare this with what is already known about the desired behavior.
What I will keep in my mind for my future testing projects is that tours are a pretty helpful instrument to get a quick overview of the application, find critical parts and/or frequently used features, and generate ideas or guide tests for them.