Walk through testing a search filter with date ranges, dropdowns, and free text.

Per-dimension test design:

Date range filter:

• BVA on the start date: today, today-1day, far past, far future.
• BVA on the end date: same.
• Boundary conditions: start = end (single-day query), start > end (invalid), start = null (open-ended), end = null.
• Time zones: does the filter use user's TZ, server TZ, or UTC? Test a date that's "today" in one TZ but "yesterday" in another.
• Daylight saving: filter spanning a DST transition.

Dropdown filter (e.g. category):

• Each option selected individually.
• Multi-select if supported: 1 selected, all selected, none selected.
• Default state: what's selected when the user lands.
• Localisation: option labels translate; sort order is locale-aware.

Free text filter:

• Empty, whitespace-only, single character, very long.
• Special characters and operators if supported ("quoted phrases", AND/OR).
• Internationalisation: non-ASCII, RTL.
• SQL injection / XSS attempts.
• Typo tolerance and stemming if the search engine supports them.

Combinatorial coverage: with 3 dimensions, full combinatorial would be huge. Use pairwise to cover every pair (date × dropdown, date × text, dropdown × text) plus targeted full combinations for highest-risk pairs. ~15–25 cases is realistic.

Scenarios that cut across all filters: clear / reset filters (each individually, all at once); persistence across pagination; URL state (filter values reflected in URL query string; bookmarking works); browser back/forward; no-results empty state; concurrent updates (does a newly added matching item appear live or only on next request?); performance latency at typical and worst-case combinations.

The senior signal: organising the test design by dimension (each filter independently) plus combinatorial (the cross-product), plus the cross-cutting UX/state concerns.