Как определить ограничения по периоду даты для тестирования?

Что проверяют

Умеете ли вы найти границы, которых нет в требованиях явно, и превратить их в тестовые данные. Интервьюер ждёт классы эквивалентности и граничные значения применительно к датам, а следом обычно даёт конкретику: «Отчёт строится за период не больше 31 дня, что проверите?»

Как отвечать

Сначала источники ограничений: требования и бизнес-правила (бронирование не раньше завтрашнего дня, возраст от 18 лет), тип поля в базе и API (date или timestamp with time zone), настройки компонента календаря, сроки из законодательства. Если границы в требованиях нет, это вопрос аналитику, а не допущение тестировщика.

Дальше разбиение и границы:

• классы: дата внутри периода, раньше начала, позже конца, пустое значение, неверный формат, конец раньше начала;
• границы: сама граничная дата, день до и день после. Для «не больше 31 дня» это периоды длиной 30, 31 и 32 дня, и обязательно выясните, включается ли последний день;
• календарь: 29 февраля в високосный год и его отсутствие в обычный, переход через конец месяца и года, месяцы по 30 и 31 дню;
• время и зоны: 23:59:59 против 00:00 следующего дня, пользователь и сервер в разных часовых поясах, переход на летнее время, если продукт работает с такими зонами;
• далёкие даты: 1900 год, 9999 год, январь 2038 года для 32-битного Unix-времени.

Возраст и сроки считают от текущей даты, поэтому тесты не должны зависеть от дня запуска. В автотестах время фиксируют: page.clock в Playwright, подмена Clock в Java, freezegun в Python.

Где спотыкаются

Проверяют только значения внутри периода. Большинство дефектов живёт ровно на границе: включительно или нет, < или <=.

Забывают про часовые пояса. Запись, созданная в 01:00 по Москве, на сервере в UTC относится к предыдущему дню и выпадает из отчёта.

Зашивают даты в тесты. Проверка «пользователю ровно 18 лет» с фиксированной датой рождения проходит сегодня и падает через год.