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;
- Day (text field)
- Month (text field)
- Year (text field)
- Are all elements valid?
Scenarios where you would use Date of Birth Functionality
- Account / User Registration
- 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 ID||Requirement Description||Notes|
|REQ-DOB-0001||The system must capture the date of birth.|
|REQ-DOB-0002||The date of birth must be in UK format.|
For example, the date format of the field must be in the order below.
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-0003||Manual 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-0004||User 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-0005||Day 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-0006||Month 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-0007||Year 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-0008||Leap 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-0009||Validate 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-0010||Date of Birth Calculation|
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 Number||Test Step||Requirement ID||Expected Result||Actual Result||Status(Pass / Fail)||Positive / Negative Test|
|1||Access user registration form page for Application under Test (AUT)||User lands on the user registration page.||+|
|2||Skip the Date of birth field and fill out valid data in the rest of the form||Valid data is filled out in all fields EXCEPT the Date of birth field.||+|
|3||Negative 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.
|4||In the ‘month’ field the User enters a valid numerical value.||A valid numerical value is entered||+|
|5||In the ‘Year’ field, the User enters the correct value.||The correct year of birth is inputted.||+|
|6||User 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..
|7||Negative 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||–|
|8||User clicks submit||The 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..
|9||Testing of business rule|
In the ‘day’ field the user enters the value ‘31’.
|The value ‘31’ is entered into Day field.||–|
|10||In the month field, the user enters the value 09|
Note: 9 = September
|The value ‘09’ is populated in the Month field.|
|11||In the year field, the user enters a correct value.|
|A correct value is entered into the ‘Year’ field.|
|12||User clicks on ‘Submit’||A ‘useful’ error message is displayed.|
The message informs the user that September does not have 31 days.
Please amend accordingly.
|13||User amends day value to 30||Day field is populagted with ‘30’.|
|14||User 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.
|Boundary 1||Boundary 2|
|0 -13||13 >|
You have a number of partitions as part of this test, they are;
|Partition 1||Partition 2|
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.
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.
If you ever come across testing date fields, then you might also be interested in writing test cases for a calendar application.