Test Report:
Local.ly is a web application that enables exchange students to book reservations for local experiences of their choice. The first part of the process is for the user to choose a date and a corresponding experience. Each reservation request has to be confirmed by a local guide. Once this is done, the user receives a confirmation email and is confirmed for the experience. The user can either attend or cancel the reservation. Users who attend the experience receive an email once the event date has been reached. At this point, a user is able to write and submit feedback to the local guide. We defined requirements that should occur in order for the process to be running correctly:
1) Users should not be able to reserve experiences in the past - This was tested by trying to pick a date in the past.
2) Users should not receive a feedback Email if the event has not been attended - This was tested by reserving an experience, and seeing if an email was sent on the day of the experience.
3) Users should not be able to write feedback if the event has not been attended - This was tested by reserving an experience and trying to write feedback without confirming the experience's attendance. The feedback button should not be clickable.
4) Users should receive an Email once a local guide confirms the reservation request - This was tested by reserving an experience and seeing if an email was received after the reservation confirmation.
5) Users should not be able to have reservations that overlap in time - This was tested by reserving experiences on the same date that occur at similar times. As an experience's time and duration are specified, an overlap can be deliberately obtained. In this case, the user has to be notified with an email, and the overlapping experience is canceled.
6) Users should receive experience recommendations for each selected date - This was tested by picking a date and seeing if there are any entries that are highlighted in yellow. These depict the recommended experiences, based on past reservations or the overall number of reservations.
7) Users should not be able to reserve experiences that exceeded their group capacity - This was tested by deliberately reserving a particular experience multiple times by many users until the capacity was exceeded. A reservation for this experience is then not possible any longer.
Each requirement was tested extensively multiple times. Some testing scenarios take longer than others, but most tests could be executed in a few minutes.
=================================================================
Example Test Case 1 - The user logs in, picks a date (today's date) and reserves a few experiences ("Morning Run - Prater", "Daytrip to Stift Melk", "VR Games at VREI"). The local guide confirms the reservations and the user receives the emails immediately. User logs back onto the site and confirms attendance. The user receives a reminder email to write feedback. User logs back onto the site to write feedback and submits it.
=================================================================
Example Test Case 2 - The user logs in, picks a date (today's date) and reserves an experience ("VR Games at VREI"). The user reserves another experience that is adjacent to the first experience ("Escape the Room"). The local guide confirms the first reservation and the user receives an email. The user also receives a second email that states the cancellation of the overlapping experience.
=================================================================
Example Test Case 3 - The user logs in, picks a date (today's date) and reserves an experience ("VR Games at VREI"). The local guide confirms the first reservation and the user receives an email. The user logs back onto the site to give feedback. The feedback button is deactivated even though the experience's date has been reached since attendance was not confirmed.
