To write test cases for a Calendar Application, ensure you have a list of in depth requirements. Create a RTM and then create test cases that contain both positive and negative tests. Consider both functional and non functional requirements.
I don’t know about you but I can’t live without my Outlook calendar.
I use it to plan my day and prioritise all my personal and work life.
It got me thinking about how to write test cases for a calendar based software application.
In this article I’ll go through some test cases and scenarios that you might want to think about when writing your test plan and test strategy.
Table of Contents
Application Under Test Overview
The Application under test can be any tool that uses a calendar based control. For example a date picker or a text box field where a user needs to enter ‘something’.
Calendar applications have many uses. For example, scheduling tools are the first thing that comes to mind.
Email clients such as Outlook is a good example of a thick client.
There are also many thin clients (Web based) tools such as Asana, Calendly and Monday.
This article will only cover software testing during the system, integration and acceptance stages.
Unit tests are outside the scope of this article.
Test automation will not be covered in this article but there is no reason why each test scenario below cannot be built into an automation regression testing suite.
|Assumption Number||Description of Assumption|
|001||The application will be accessible via desktop, tablet and mobile|
High Level Test Scenarios
- User wants to add an item to the calendar
- User wants to include and invite an attendee to their calendar item.
- User wants to upload an attachment to their calendar item from desktop
- User wants to upload an attachment to their calendar item from tablet
- User wants to upload an attachment to their calendar item from mobile device
- User wants to make an amendment to their calendar item.
- User wants to cancel their calendar item.
- User wants to remove an invitee.
- User wants to share an online video meeting link (e.g. Zoom/WebEx) to their invite.
Positive Test Cases
Each positive test case will allow you to test a ‘sunny day’ or happy path.
- Verify Calendar Application is being rendered correctly according to design specification. (Layout, icons, colours, design elements etc)
- Verify Calendar Year, Month, Day and Date is displayed as per requirement
- Enter a Valid Date – (This is usually via a date picker calendar control or a text box).
- In the Date Field enter a Valid Month
- In the Date Field enter a Valid Year
- In the Day Field enter a Valid Input
- In the Date Field enter a Valid End Date
- Verify Calendar Control is visible when selected.
- Verify the calendar application displays the current date
- Verify the date format is as expected (this will differ depending on your country and language).
- Verify more than one person cannot edit the same record concurrently.
Negative Test Cases
As Part of your negative testing scenarios, you can incorporate the ones below.
Each negative test case should aim to ‘break’ or generate an exception to see how the system under test handles errors.
This is where you will find the majority of your defects so it’s important for the Tester to ensure as much attention to detail as possible here.
- Enter a Invalid Date
- In the Date Field enter an Invalid Month
- In the Date Field enter an Invalid Year
- In the Date Field enter an Invalid End Date
- In the Day Field enter an Invalid Input
UI Testing and GUI Test Cases
Below are examples of functional tests you may want to consider if you have a Graphic User Interface (GUI).
- Verify Filtering
- Find something using the Search feature.
- Database Integration Testing – Check that correct data is being displayed.
- File Upload Functionality
- Sending Emails
- Export Functionality
- Sharing Functionality
Performance Testing Scenarios
- Verify that [x] concurrent users can use the Application
- Does the page render within [x] seconds?
IT Security Testing Scenarios
Data privacy is always a high priority and should always be treated as such.
I’ve worked on an organisational level Microsoft Office Upgrade where GDPR was deployed.
One thing that was a learning curve, especially with Outlook was that nobody should be able to see other people’s meeting info or calendars.
So for example, if you have meeting rooms in your organisation and want to book them, you should not be able to see other meetings in the calendar which can identify others.
Also, you should not be able to view other people in your organisation’s calendars.
So testing scenarios would be something like;
- A User can only see their own meetings in a shared calendar
- A User cannot see a random person’s shared calendar
I’m not a GDPR expert so please consult your DPO, but these were key takeaways that I thought were useful.
Test Scenarios you might want to consider for a Calendar App would be;
- Database backup and recovery
- Usability of the application
- Data Redundancy – Verify that the application is hosted on at least two data centers in different locations.
- Verify Virtual machines are of a [x] specification in order to be able to run the application.
Notes and Considerations when testing a Calendar Application
The expected result for each of your test conditions should be driven by your requirements documentation.
The best way to do this is to create a Requirements traceability matrix and populate all requirements there.
If you’d like to know more on how to write a test case, or see an example template then you should read the article to acquire this knowledge first.
I’m not generally a fan of exploratory testing but if you do have time then there’s no harm in doing it.
I prefer to ensure coverage has been achieved by validating each requirement.
This is what we call specification based testing.
Summary and Wrap Up
So when writing test cases for a calendar application, ensure that you understand the type of application you’re testing.
Understand the requirements and any business logic.
As always, I like to recommend you have all your requirements in a RTM to monitor coverage.
Don’t forget to be creative and have fun when designing your tests.
As always, if you have any feedback, please reach out to me.