How to Write Test Cases for Date of Birth: Your FREE Detailed Functional Testing Example

Test cases for Date of Birth featured image 800x419

In this article I will talk about how to design test cases for the date of birth (DOB) functionality.

This piece of functionality is VERY important as it has many uses. 

Some of these uses include areas such as security and identification.

Feel free to use the test case and amend it accordingly to suit your needs.

Now before you continue, you might want to learn more about writing test cases

What are the key things you should test for Date of Birth Functionality?

The date of birth is only one field.

However, in my opinion, it’s one of the most important fields when registering a user’s profile.

Let’s break down the elements;

  1. Day (text field)
  2. Month (text field)
  3. Year (text field)
  4. Are all elements valid? 

Scenarios where you would use Date of Birth Functionality

  • Verifying the age of a User when they register for a product or service
  • Resetting login credentials when a user forgets
  • Admin User as part of a series of security questions

Let’s elaborate on the scenarios mentioned above

Scenario 1: Test Cases for Date of Birth – Verifying the age of a user

Age verification is used across so many different platforms.  Below are some test scenarios that you may want to consider.

  • User wants to create a social media/email account and is required to be at least 13 years of age. 
  • User is applying for a UK provisional driving licence.  The minimum age is 17.
  • Purchasing a restricted product or service online.  For example watching restricted YouTube videos which require you to conduct an age check.
  • Buying alcohol or gaming services online!

Scenario 2: Test Cases for Date of Birth – Resetting login credentials when a user forgets

  • When a user forgets their credentials, the system may ask for further verification to prove the user’s identity.

Scenario 3: Test Cases for Date of Birth – An Admin User of a System asks the DOB as part of a series of security questions

  • Similar to the above scenario however with a human element.  This scenario is where an Application Admin User wants to verify the User calling is indeed who they say they are and the DOB is part of a set of security verification questions.  

Business and Functional Requirements

You should ALWAYS try and get some requirements if your testing is going to be high quality.

I always tell my non testing colleagues that as specification based testers, we are only as good as the requirements we have.

Take note my Business Analyst friends. 

Let’s break down some example requirements that I have created for you.

I’ve tried to be detailed but don’t want to go overboard.

Where possible, you should always try and create a Requirements Traceability Matrix (RTM) where you can store all your project requirements. 

Requirement IDRequirement DescriptionNotes
REQ-DOB-0001The system must capture the date of birth.
REQ-DOB-0002The date of birth must be in UK format.

For example, the date format of the field must be in the order below.

DD/MM/YYYY
D = Day (numerical format)M = Month (numerical format)Y = Year (numerical format)
If a drop down option is required then the UI can update and display the minimum start date that = 13 years old.

It can also accept manual input.
REQ-DOB-0003Manual DOB Form Entry
The system must give the user the option to enter the date of birth manually
This requirement can be expanded to include a date/calendar control option.  

However for simplicity we will use the manual form option.

From a Usability perspective, the date picker is less tedious and prone to less validation issues arising.
REQ-DOB-0004User Age Restriction

The minimum user age is 13.  

The system should automatically reject any user who is under the age of 13 from the current date.
REQ-DOB-0005Day Field Validation
The day field must be a valid number from between 1 to 31.

DFBR1 – Day Field Business Rule 1
The system should reject any value less than 1 and more than 31.
REQ-DOB-0006Month Field Validation
A valid month field will be a number from 1 to 12.

Month 1 represents January and Month 12 representing December.

MFBR1 – Month Field Business Rule 1
When the user enters the Month as a numeric value, the system should validate if the DAY value is correct.
REQ-DOB-0007Year Field Validation
The year field is a 4 character numeric value which should go back no further than 125 years from the current year. 

For example if today is 1st September 2021, the earliest date the system can go to is September 1st 1896.
There is a number of people alive that are over 110 years old, as a result I’ve added a but more contingency.
REQ-DOB-0008Leap Year Validation
If a person is born in a leap year, the system should validate;

The year they were born was in fact a Leap Year.

Default their birthdate to March 1st on non-leap years.

If the year they entered is incorrect, the system should display an error message.
Note:  In some countries, defaulting a leap year to Feb 28th is considered illegal. 

In this case, we will use the UK Legal perspective which is to use March 1st.
REQ-DOB-0009Validate Correct Date
When a user enters the entire date of birth, the system should check its validity.

Business Rule 1:
Validate the day conforms to the correct month.
REQ-DOB-0010Date of Birth Calculation

User Journey

The test case will typically include positive and negative validation.  It will look something like the following;

  • User navigates to the registration page
  • When prompted, User enters an invalid date of birth
  • User enters a valid date of birth (but less than 13 years old by mistake)
  • System displays error message informing the user they cannot register if they are under 13 years of age
  • User enters their correct date of birth (which is over the age of 13)
  • System processes and validates the date as being correct.

Test Case for Date of Birth Example

Step NumberTest StepRequirement IDExpected ResultActual ResultStatus(Pass / Fail)Positive / Negative Test
1Access user registration form page for Application under Test (AUT)User lands on the user registration page.+
2Skip the Date of birth field and fill out valid data in the rest of the formValid data is filled out in all fields EXCEPT the Date of birth field.+
3Negative test scenario
In the ‘day’ field input an invalid number such as =>32.
The day field is populated with an invalid entry.

For example: 32/MM/YYY
Note: depending on how your requirements are written, the application can display an error message at this point or once all the date field has been populated.
4In the ‘month’ field the User enters a valid numerical value.A valid numerical value is entered+
5In the ‘Year’ field, the User enters the correct value.The correct year of birth is inputted.+
6User clicks on ‘Submit’The system displays an error message warning that the Day field is incorrect.

Note: All fields are still populated with the manual data entered so the user can make a correction.

Fields are still editable..
+
7Negative Test Case
In the day field, the user enters a blank space.
All other fields are still populated and day field is updated left blank
8User clicks submitThe system displays an error message warning that the Day field is incorrect.

All fields are still populated with the manual data entered so the user can make a correction..
+
9Testing of business rule
In the ‘day’ field the user enters the value ‘31’.
The value ‘31’ is entered into Day field.
10In the month field, the user enters the value 09
Note:  9 = September
The value ‘09’ is populated in the Month field.
11In the year field, the user enters a correct value.
E.g. 1985
A correct value is entered into the ‘Year’ field.
12User clicks on ‘Submit’A ‘useful’ error message is displayed.

The message informs the user that September does not have 31 days. 

Please amend accordingly.
13User amends day value to 30Day field is populagted with ‘30’.
14User clicks on ‘Submit’The system;
a) processes the form
b) validates the date of birth
c) validates against the business rules

Redirects the user to registration confirmation page.

I didn’t want to make this test case too long but you can also add some test steps to ensure;

  • User is over 13 years of age
  • User that is born on 29th February is defaulted to 1st March as their date of birth (except on leap years).
  • Validate that the Year does not go further back than 125 years from the current date.

If you have a calendar control, that ‘thing’ where you select the date with a mouse, testing this should be a lot easier.

This is because there are less functional tests and less test data to prepare.

As part of the registration process, you may want to also consider test cases for change password functionality.

Boundary Value Analysis

Below are some boundary values you may want to think about.

Age

Boundary 1Boundary 2
0 -13 13 >

Equivalence Partitioning

You have a number of partitions as part of this test, they are;

Age

Partition 1Partition 2
0-12>13

A Great Addition to your Regression Testing Suite

I love a detailed functional test like this.  Why?

Because I can add it to my regression testing pack.

Once you have all the intricate details, you can literally run these tests as and when you need them.


Regardless of whether they are manual or automated tests.

Summary

Hopefully the above should be a good test case for date of birth functional testing.

I absolutely love these types of black box testing techniques as I remember doing many in my career.

Working in the Quality Assurance arena isn’t easy but this is one of the many challenges of being a software tester.