QAble

Browse by type

Explore all services
Functional
Functional Testing
End-to-end feature validation
Software Testing
Full-stack QA across disciplines
Software QA
Process, standards & audit QA
Independent Testing
Vendor-neutral V&V & sign-off
Cyber Security Testing
Pen testing & exploit validation
Enterprise Testing
ERP, CRM & core platform QA
Manual Testing
Human-driven QA testing
Exploratory Testing
Discover hidden edge cases
User Acceptance Testing
Business-aligned validation
Usability Testing
Real user experience testing
UI/UX Testing
Interface & interaction QA
Accessibility Testing
WCAG compliance testing
Accessibility Audit
Compliance gap assessment
Accessibility Remediation
Fix accessibility violations
Digital Accessibility
End-to-end inclusive design QA
Security & VAPT
Vulnerability assessment
VAPT Testing
Penetration testing & compliance
Performance Testing
Load & stress testing
Non-Functional Testing
Performance, security & reliability
Compatibility Testing
Cross-device & browser QA
Scalability Testing
Capacity & growth QA
Agile Testing
Sprint-aligned QA
Localization Testing
Language & regional QA
Digital Testing
Digital experience QA

What's New

Solution

Tesbo-X, Playwright Automation Framework

Intelligent test selection, parallel CI execution, and rich trace reporting unified in a single automation system.

Try for Free →
View all services
About UsWhy QAbleCertificationsCareers
Knowledge HubBlogQAble WeeklyCase StudiesEbooksUtilities
BetterBugs
BetterBugs
Tesbo-X
Tesbo-X
Talk to QA Advisor
Browse the Knowledge Hub32 resources
/Test Cases/Date picker test cases

Test cases

Date picker test cases, where the defect is usually one day off

Twenty six cases covering timezone shifts, ambiguous day and month order, impossible typed dates, minimum and maximum limits, leap years, daylight saving, ranges, disabled dates, keyboard operation and screen reader announcements.

26cases/7coverage types/9boundary cases/FreeCSV download

All 26 test cases, ready to copy

Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.

Last updated

26 worked examples

DATE-01

Select a date from the calendar

TypeFunctionalPriorityHigh
Test data
Any valid selectable date
Expected result
Field displays the date in the expected format, the calendar closes, and the value saved matches the date shown to the user exactly.
DATE-02

Open the picker and confirm the default state

TypeFunctionalPriorityMedium
Test data
Empty field, then a field with an existing value
Expected result
Empty opens on the current month with today marked but not selected. A populated field opens on the month of the existing value with it highlighted.
DATE-03

Store the selected date across a timezone boundary

TypeBoundaryPriorityHigh
Test data
Select the first of a month with the device set to UTC minus 8, then to UTC plus 13
Expected result
The stored date is the date chosen, not shifted by a day. Calendar dates must not be converted through a timestamp with a local midnight assumption.
DATE-04

Verify the date displayed after saving and reloading

TypeStatePriorityHigh
Test data
Save a date, reload, and view it in another timezone
Expected result
Identical date in both places. A calendar date is a date, not an instant, and should be stored as such.
DATE-05

Type a date directly into the field

TypeFunctionalPriorityHigh
Test data
The documented format, typed by hand
Expected result
Accepted and parsed, the calendar reflects it, and no reformatting loses the value.
DATE-06

Type an ambiguous date

TypeBoundaryPriorityHigh
Test data
03/04/2026 with the locale set to United Kingdom, then to United States
Expected result
Parsed according to the stated locale, and the expected format is visible next to the field. Ambiguous parsing that differs from the placeholder is a real financial risk on contracts and bookings.
DATE-07

Type an impossible date

TypeNegativePriorityHigh
Test data
31/02/2026, 00/01/2026, 32/13/2026
Expected result
Rejected with a clear message. Silent rolling forward to 3 March is worse than an error, because the user never notices.
DATE-08

Type a partial or malformed value

TypeNegativePriorityMedium
Test data
12/, 2026, 1-1-26, text, an empty string after clearing
Expected result
Refused or completed deliberately, never left in a half parsed state that submits as something unexpected.
DATE-09

Enter a two digit year

TypeBoundaryPriorityMedium
Test data
01/01/26, then 01/01/99
Expected result
Interpreted by a documented pivot rule and echoed back in full, so the user can see whether 1926 or 2026 was understood.
DATE-10

Respect the minimum selectable date

TypeBoundaryPriorityHigh
Test data
The minimum date, one day before it, and the same values typed rather than clicked
Expected result
Minimum accepted, earlier refused, and the rule enforced on the typed path and on the server, not only by greying out cells.
DATE-11

Respect the maximum selectable date

TypeBoundaryPriorityHigh
Test data
The maximum date, one day after it
Expected result
Maximum accepted, later refused with the limit stated.
DATE-12

Handle a minimum of today as midnight passes

TypeStatePriorityHigh
Test data
Open the picker just before midnight, select tomorrow, submit just after midnight
Expected result
Either still valid or refused with a clear message. The boundary must be evaluated server side at submission, not fixed when the page loaded.
DATE-13

Select 29 February in a leap year and a non leap year

TypeBoundaryPriorityMedium
Test data
29/02/2028, then 29/02/2027
Expected result
Available in the leap year, absent and rejected if typed in the non leap year.
DATE-14

Select a date across a daylight saving transition

TypeBoundaryPriorityHigh
Test data
The day clocks change in the user region, plus the day either side
Expected result
The date stored and displayed is unchanged. Durations calculated from it account for the 23 or 25 hour day.
DATE-15

Verify disabled dates cannot be chosen by any route

TypeSecurityPriorityHigh
Test data
A blocked date such as a weekend or a fully booked day, submitted directly to the endpoint
Expected result
Refused by the server. Disabled cells in the interface are a convenience, never the rule.
DATE-16

Select a range and confirm ordering

TypeFunctionalPriorityHigh
Test data
Start after end, then the same date for both
Expected result
Either the values swap with a visible indication or the second selection is refused. A same day range is valid or refused deliberately, and the rule is stated.
DATE-17

Enforce a maximum range span

TypeBoundaryPriorityMedium
Test data
A span at the limit, then one day beyond
Expected result
Limit accepted, beyond refused with the maximum stated in the message.
DATE-18

Clear a populated date

TypeFunctionalPriorityMedium
Test data
Use the clear control, then delete the text manually
Expected result
Both routes empty the value and the stored record, and a required field then reports itself as missing rather than keeping the old value.
DATE-19

Navigate months and years

TypeFunctionalPriorityMedium
Test data
Move across a year boundary in both directions, then jump by year
Expected result
December to January advances the year, and any month or year jump control lands on the intended month.
DATE-20

Verify the locale calendar layout

TypeCompatibilityPriorityMedium
Test data
Locales where the week starts on Sunday, Monday and Saturday
Expected result
First day of week, month names and day abbreviations follow the locale, and a right to left locale mirrors the layout.
DATE-21

Operate the picker by keyboard only

TypeAccessibilityPriorityHigh
Test data
Tab to the field, arrow keys, Page Up and Page Down, Home, End, Enter and Escape
Expected result
Arrows move by day, Page keys move by month, Enter selects, Escape closes without changing the value, and focus returns to the field.
DATE-22

Verify screen reader behaviour

TypeAccessibilityPriorityHigh
Test data
NVDA or VoiceOver on the field and inside the calendar
Expected result
The field announces its expected format, the focused cell announces the full date, disabled dates announce as unavailable, and the selected date is confirmed after choosing.
DATE-23

Verify behaviour on mobile

TypeCompatibilityPriorityHigh
Test data
iOS Safari and Android Chrome, native control and custom control
Expected result
The touch target is large enough, the control is not obscured by the on screen keyboard, and a native picker returns the same value format as the custom one.
DATE-24

Paste a date into the field

TypeBoundaryPriorityMedium
Test data
Paste from a spreadsheet, including a value with a trailing space and one with a time appended
Expected result
Trimmed and parsed if valid, refused clearly if not, and never silently truncated.
DATE-25

Submit the form without touching the picker

TypeNegativePriorityHigh
Test data
A required date field left untouched, with a placeholder or a prefilled default
Expected result
A required empty field blocks submission. A prefilled default is only submitted if defaulting is intended, because an unnoticed default date is a common source of wrong bookings.
DATE-26

Verify the value that reaches storage and reports

TypeStatePriorityHigh
Test data
Inspect the API payload, the database value and an exported report for the same selection
Expected result
All three agree with what the user saw. This is the single check that catches timezone and format defects before customers do.

What goes in each field

ID

Required

Stable identifier, prefixed by module.

Test case

Required

What is being verified, in one line.

Type

Functional, negative, boundary, security, state, performance, accessibility or compatibility. Use it to check coverage is spread rather than clustered on the happy path.

Priority

Risk based. Anything that can store a different date from the one the user selected is High, because a date that is wrong by one day breaks bookings, billing periods and reporting silently.

Test data

The specific values, including the invalid and boundary ones.

Expected result

Required

The precise observable outcome, including message text where the wording itself is the requirement.

How To Use This

Change the device timezone and repeat

Clicking a calendar cell always works. These four conditions are where the stored value stops matching the selection.

Test in two timezones

Select the first of a month at UTC minus 8 and at UTC plus 13. A date stored through a local midnight assumption shifts by a day.

Type, do not click

Typed input is where 03/04 becomes March or April depending on locale, and where 31 February silently becomes 3 March.

Send a disabled date

Greyed out cells are presentation. Post the blocked date straight to the endpoint and confirm it is refused.

Follow the value to storage

Compare the interface, the API payload, the database row and an exported report. All four must agree.

What Most Sets Miss

Why date fields fail in production

The off by one day defect is the reason this control deserves its own test set. It happens when a calendar date is stored as an instant: the picker produces local midnight, that is converted to UTC, and a user west of Greenwich sees the previous day while a user in New Zealand sees the next. A date of birth, a contract start or a billing period is a date, not a moment in time, and should be stored as one. Testing in a single timezone will never reveal it.

Ambiguous parsing is the second. Any field that accepts typing has to decide whether 03/04/2026 is March or April, and the answer must match both the placeholder and the locale. This is not a cosmetic issue on a booking or a contract, and the fix is to state the expected format next to the field and to echo the parsed date back in an unambiguous form.

Silent correction is the third and the most deceptive. A field that accepts 31 February and stores 3 March has produced a wrong record that nobody will question, because no error was shown. Rejecting impossible dates is better behaviour than helpfully rolling them forward.

Finally, validation applied only to calendar cells. Minimums, maximums and blocked dates are frequently enforced by disabling cells, then bypassed entirely by typing or by a direct request. Every date rule needs a server side check, and the midnight case deserves its own test: a form opened at 23:58 and submitted at 00:01 was validated against yesterday.

Suggest an improvement

Dates driving money or bookings?

QAble tests date handling end to end, including timezone behaviour, locale parsing and what actually lands in storage and in reports.

Functional testing services

More test case sets

View all

Test cases for a login page

Test cases25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.

Test cases for a registration form

Test cases28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.

Test cases for search functionality

Test cases28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.

Test cases for a shopping cart

Test cases27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.

Test cases for checkout and payment

Test cases30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.

Test cases for file upload

Test cases28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.

Test cases for forgot password

Test cases26 cases on reset token expiry, single use enforcement, session invalidation and the enumeration and rate limit gaps that are routine here.

Test cases for OTP verification

Test cases26 cases on expiry, resend throttling, attempt limits, code reuse, delivery failure and the brute force window teams forget to close.

Test cases for user roles and permissions

Test cases26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.

Test cases for form validation

Test cases27 rules-based cases on required fields, length and numeric boundaries, client and server parity, hidden field tampering and error accessibility.

Test cases for pagination

Test cases24 cases on ordering stability, records changing mid-session, page size caps, deep offset cost, permission-filtered totals and state restore.

Test cases for push notifications

Test cases26 cases on app states, deep link routing, token release on sign out, lock screen privacy, preferences, provider failures and platform differences.

Test cases for reports and data export

Test cases25 cases on permission filtering in the file, spreadsheet formula injection, encoding, typed numbers and dates, row limits and audit logging.

Test cases for a chatbot

Test cases28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.

Sources

Want date handling proven, not assumed?

QAble covers functional and boundary paths with ISTQB-certified engineers. Start with a free QA audit of your product.

Talk to QA Advisor