Как протестируешь совершеннолетний возраст при отправке запроса

Подход к тестированию валидации совершеннолетнего возраста в запросе

Тестирование валидации возраста, особенно при проверке совершеннолетия (обычно 18+), — это комплексная задача, которая затрагивает граничные значения, форматы данных, бизнес-логику и безопасность. Вот мой детальный план, основанный на 10+ годах опыта в QA.

1. Анализ требований и понимание контекста

Перед тестированием я уточню ключевые моменты:

• Порог совершеннолетия: Всегда ли это 18 лет? Есть ли региональные различия (например, 19, 21)?
• Контекст запроса: Это регистрация, покупка алкоголя/сигарет, доступ к контенту?
• Входные данные: Какие именно данные передаются в запросе? Обычно это дата рождения (Date of Birth - DOB) или уже рассчитанный возраст (число). Предпочтительнее тестировать на основе даты рождения, так как это более фундаментальный и проверяемый параметр.
• Логика расчета: Как именно считается возраст? По полным годам на текущую дату? С учетом часового пояса?
• Формат даты: YYYY-MM-DD, DD.MM.YYYY, timestamp?

2. Разработка тест-кейсов

Основной фокус — анализ граничных значений (Boundary Value Analysis) и классы эквивалентности (Equivalence Partitioning).

Позитивные тесты (валидный возраст 18+)

• Ровно 18 лет сегодня: Пользователь, у которого сегодня день рождения и ему исполняется 18 лет.

  // Пример тела запроса (POST /verify-age)
  {
    "dateOfBirth": "2006-08-08" // Предположим, сегодня 08.08.2024
  }
  

    **Ожидаемый результат:** Успех (HTTP 200, `{"isAdult": true}`).

• Старше 18 лет (1 день, 1 год, 10 лет): Стандартные валидные случаи.
• Минимальная валидная дата: Рассчитывается как Текущая дата - 18 лет. Для тестов "на завтра" нужно использовать конкретные даты или моки.

Негативные тесты (несовершеннолетний возраст < 18)

• Ровно 17 лет и 364 дня (или 365 для високосного): На один день младше совершеннолетия — критическая граница.

  {
    "dateOfBirth": "2006-08-09" // На день позже, чем в примере выше (08.08.2024)
  }
  

    **Ожидаемый результат:** Ошибка (HTTP 403/422, `{"isAdult": false, "error": "Age restriction"}`).

• Значительно младше (0 лет, 10 лет).
• Дата рождения в будущем: Некорректные данные, которые должны обрабатываться отдельно.

  {
    "dateOfBirth": "2030-01-01"
  }
  

    **Ожидаемый результат:** Ошибка валидации (HTTP 400, `{"error": "Invalid date of birth"}`).

Тесты на корректность логики расчета

• Високосный день (29 февраля): Как система обработает дату рождения 29.02.2008 при проверке 28.02.2026 и 01.03.2026?
• Смена часовых поясов (Time Zone): Запрос выполняется в момент перехода через полночь по UTC. Пользователь из Австралии (где уже наступил следующий день) может быть "технически" старше, но по местному законодательству — нет. Важно понимать, по какому времени (UTC, локальному) ведется расчет.
• Разные форматы даты: Проверка поддержки оговоренных форматов и обработка неверных (DD-MM-YYYY, MM/DD/YYYY).

Некорректные и опасные входные данные (Security & Robustness)

• Пустое значение, null, отсутствие поля.
• Неформатная строка: "не дата", "01/13/2020".
• Экстремальные/нереальные даты: "1800-01-01", "0001-01-01".
• Инъекции: Попытки внедрения SQL, XSS или других команд через строку даты.

  {
    "dateOfBirth": "1990-01-01'; DROP TABLE users;--"
  }
  

• Отрицательные timestamp.
• Очень большие числа (переполнение).

Тестирование API-контракта

• Методы запроса: Работает ли только POST? Возвращает ли ошибку GET?
• Заголовки (Headers): Проверка Content-Type: application/json.
• Коды ответов (Status Codes): Соответствуют ли они REST-практикам (200, 400, 403, 422, 500)?
• Структура ответа: Единый формат для успеха и ошибок.

3. Техники и инструменты

• Ручное тестирование: Для первоначального исследования и проверки сложных сценариев (високосные годы).
• Автоматизация: Обязательна для регрессионной проверки граничных значений. Я бы использовал Postman (для коллекции) или написал скрипты на Python (pytest + requests) или JavaScript (Jest + Supertest).

  # Пример теста на Python (pytest)
  import pytest
  import requests
  from datetime import datetime, timedelta
  
  def test_age_verification_exactly_18():
      today = datetime.today()
      birth_date = (today - timedelta(days=365*18)).strftime('%Y-%m-%d')
      payload = {"dateOfBirth": birth_date}
      response = requests.post("https://api.example.com/verify", json=payload)
      assert response.status_code == 200
      assert response.json()["isAdult"] is True
  
  def test_age_verification_one_day_younger():
      today = datetime.today()
      birth_date = (today - timedelta(days=365*18 - 1)).strftime('%Y-%m-%d')
      payload = {"dateOfBirth": birth_date}
      response = requests.post("https://api.example.com/verify", json=payload)
      assert response.status_code == 403
      assert response.json()["isAdult"] is False
  

• Моки и стабы: Чтобы зафиксировать "текущую дату" в тестах и не зависеть от реального времени.
• Тестирование в разных средах: Dev, Stage, Preprod.

4. Дополнительные соображения

• Логирование (Logging): Проверяю, логируются ли попытки неудачной верификации (для аудита и анализа мошенничества).
• Производительность (Performance): Как ведет себя endpoint при высокой нагрузке (1000+ запросов в секунду с разными датами)?
• Юридическая валидность: Совпадает ли логика расчета с требованиями законодательства целевого региона? Это вопрос к аналитикам и юристам, но QA должен поднять его, если видит расхождение.

Заключение: Моя стратегия — комбинация точного анализа границ, полного покрытия классов эквивалентности, проверки на устойчивость к некорректным данным и автоматизации ключевых сценариев. Самые важные тесты — это проверка ровно 18 лет и 18 лет минус 1 день, так как они определяют корректность бизнес-логики. Всегда начинаю с уточнения требований, потому что дьявол кроется в деталях (високосные годы, часовые пояса, формат даты).