In this how-to, we will walk through how to write test cases for a Date of Birth field. Many applications make use of Date of Birth Fields. Some examples include getting a driver’s license, making movie purchases, and gaining admission to movies. As a result, creating test cases for the date field applies to most testers. Follow along with this how-to and finish your application’s first test case by creating your free account in our test case management tool. Before starting our test case, we need to define the Acceptance Criteria.
What are the Acceptance Criteria for our age field?
As discussed in our requirements post, we must have functional requirements. So let’s go ahead and define them as such:
Description: “As a supermarket retailer with locations in both Canada and the United States, we must be able to make sales of alcohol and tobacco according to Canadian Laws and the United States Laws.”
- Only people over the age of 19 can purchase tobacco in Canada.
- Customers over the age of 18 can purchase alcohol in Canada.
- Only people over the age of 21 can purchase tobacco in the United States.
- Customers over the age of 18 can purchase alcohol in the United States.
What are the age field Test Scenarios?
We will want to document several test scenarios to create test cases for date of birth fields successfully. At a high level, they will include:
Canadian Store Tests for tobacco:
- Attempt to create a sale for a customer one day shy of their 19th birth date.
- Create a sale for a customer on their 19th birth date.
- Create a sale for a customer one day after they turn 19.
Canadian Store Tests for alcohol:
- Attempt to create a sale for a customer one day shy of their 18th birth date.
- Create a sale for a customer on their 18th birth date.
- Create a sale for a customer one day after they turn 18.
United States Tests for tobacco and alcohol:
- Attempt to create a sale for a customer one day shy of their 21st birth date.
- Create a sale for a customer on their 21st birth date.
- Create a sale for a customer one day after they turn 21.
Scenarios we would want to test and document in a test case:
- Validate the date field handles an unrealistic age by entering a date of birth equaling 123 years.
- Make sure UI date fields are always in MM-DD-YYYY.
- Ensure the format of dates sent to the server is always in YYYY-MM-DD.
- Ensure only valid dates are accepted in the date field.
Scenarios we would want to test, but not necessarily create an explicit test case for (ad-hoc test):
- Move the computer’s clock into the future and attempt to make a purchase using a date of birth equal to the future date.
- Key in dates in the UI in various formats, examples: YYYY-MM-DD, MM/DD/YYYY, MM/DD/YY, YYYY.MM.DD, along with a date spelled out.
- Enter no date in the date field.
- Ensure Leap Year birthdates do not cause issues.
Keep in mind there are diminishing returns to testing, and developers should be using a thoroughly tested library for date pickers. However, there is no need to over-test scenarios. For example, if all of the ad-hoc tests for #2 above pass, it is unlikely to turn up any bugs to continue testing permutations of the formatting.
The best thing you can do as a tester is discuss, with the developer, what the library code is doing and what it is not doing. Another quick sanity check is to review your developer’s code check-in for the story you are working on. Doing so can help target your testing efforts.
Additional Scenarios for Date Picker
- Verify calendar is displayed when the date boxes are clicked.
- Verify calendar loads correctly after selecting the date box.
- Validate calendar display matches the system date.
- Verify calendar formatting is correct dd/mm/yyyy or mm/dd/yyyy, depending on requirements.
- Validate calendar component allows a wide range of years to choose from. For example, you should be able to select a date 10 years in the past or future.
- Verify calendar widget works properly on a mobile phone and can be scrolled forward and back.
- Ensure the current date is selected and highlighted by default.
- Verify the previous and next links can be interacted with in the date picker.
- Validate the date selected in the date picker shows the same date in any corresponding date box.
Additional Scenarios for an editable date field
The following scenarios are related to an editable date field, such as the one pictured here:
- Validate the date form accepts inputs correctly. By attempting these combinations
- Verify the month and day only accept two digits.
- Verify the year only accepts four digits.
- Validate the form must be filled out and an empty field is permitted.
- Check what symbols are permitted as separators for the date (forward slash, back slash, dash).
- Verify the input field does not accept special characters.
- Validate the formatting of the accepted date matches your system’s specifications.
- Ensure only valid dates are accepted:
- Cannot enter all zeros.
- Cannot enter a day greater than 31.
- Cannot enter a month greater than 12.
- Cannot enter negative dates.
- Year must be equal to 4 digits.
- Verify Leap Year dates are accepted.
Writing Test Cases for Date of Birth Field
In this section, we will go into detail on how to write the functional test case. There are additional test cases you would want to create to handle the screen formatting validation. We are only covering a few of the functional scenarios.
Create your Date of Birth Field Common Step
Common Steps are steps that can be reused across test cases. They are great when you need to create multiple tests around the same functionality, or if you have intermediary data prep steps. When it comes to AccelaTest’s future automation efforts, they will permit you to take a hybrid approach to execute test cases. That is, you will be able to leverage automated common steps when executing your manual tests, thereby cutting your repetitive data prep time drastically.
For this date field transaction, we created a Common Step to purchase an item. As you will notice there are many parameterized values in the common step. This allows for different values to be entered when calling into the Common Step.
Test Case Details for Date Field
For this Test Case, our summary is “The test case will ensure the Date of Birth is enforced for various purchases in both Canada and United States Stores.” and pre-conditions are “All products are entered into the product database with the correct age requirements.”
Test Cases for Date of Birth Test Steps
Our Test Case for the scenarios only requires two steps. Step one is to declare where the store is located we are wanting to test (USA or CA). The second step is to call the Common Step we created earlier and loop through the specific data. Taking this approach to writing Test Cases makes your testbed much more maintainable and easier to read. As your application matures, you can make small changes to tests that are pushed to all test cases.