Какие логические проверки будешь делать с полем ФИО

Конечно. Как QA-инженер, проверка поля «ФИО» — это классический пример работы с текстовыми полями, где сочетаются валидация, обработка граничных значений и бизнес-логика. Вот детальный план логических проверок, структурированный по категориям.

1. Валидация формата и допустимых символов

Основная задача — убедиться, что система принимает только корректные данные и корректно отвергает некорректные.

• Позитивные проверки (корректные данные):

    *   Стандартное ФИО на кириллице: `Иванов Иван Иванович`.
    *   ФИО с дефисом или пробелом в фамилии/имени: `Петров-Водкин Кузьма Сергеевич`, `ван дер Ваальс Йоханнес Дидерик`.
    *   ФИО с буквой `ё`: `Серёгин Пётр Фёдорович`.
    *   ФИО на латинице (если это предусмотрено требованиями): `Smith John David`.
    *   Двойные имена/фамилии через пробел (если допустимо): `Гонсалес Торрес Мария Фернанда`.

• Негативные проверки (некорректные данные — ожидаем ошибку):

    *   **Цифры и спецсимволы:** `Иванов Иван123`, `Тест@ович Анна`.
    *   **Только пробелы или пустая строка.**
    *   **HTML-теги или скрипт:** `<script>alert(1)</script>` (проверка на XSS-уязвимость).
    *   **SQL-инъекция:** `Иван' OR '1'='1` (проверка на SQLi).

Пример тестового сценария для проверки валидации

Feature: Валидация поля ФИО

  Scenario: Успешное сохранение ФИО с дефисом
    Given Пользователь находится на форме регистрации
    When В поле "ФИО" вводится "Салтыков-Щедрин Михаил Евграфович"
    And Нажимается кнопка "Сохранить"
    Then Данные успешно сохраняются
    And ФИО отображается как "Салтыков-Щедрин Михаил Евграфович"

  Scenario: Попытка сохранить ФИО с цифрами
    Given Пользователь находится на форме регистрации
    When В поле "ФИО" вводится "Анна 7-я"
    And Нажимается кнопка "Сохранить"
    Then Отображается сообщение об ошибке "ФИО может содержать только буквы, пробелы и дефисы"
    And Данные не сохраняются

2. Проверки на граничные значения и длину

Определяем минимальную и максимальную допустимую длину поля (например, от 2 до 100 символов).

• Минимальная длина:

    *   **Граничное значение:** Ввод ровно 2 символа (`Ив`). Должно ли это быть допустимо? Часто — нет, проверяем логику.
    *   **Значение ниже минимума:** Ввод 1 символа (`Я`). Ожидаем ошибку.

• Максимальная длина:

    *   **Граничное значение:** Ввод ровно 100 символов (например, длинная составная фамилия). Система должна принять и корректно обрезать или перенести при отображении.
    *   **Значение выше максимума:** Ввод 101 символа. Ожидаем либо ошибку, либо авто-обрезание (зависит от требований). **Критично проверить, как обрезанная строка сохраняется в БД и отображается в интерфейсе.**

• Очень длинное ФИО: Проверка на переполнение буфера (ввод тысяч символов) — система не должна падать.

3. Проверки логики обработки данных (Бизнес-правила)

Это самый важный и часто упускаемый слой.

• Автозаполнение/Автоформатирование: При вводе иванов иван иванович (все строчные) система может автоматически преобразовать к Иванов Иван Иванович. Проверяем, работает ли это, и нет ли ложных срабатываний.
• Обработка лишних пробелов:

    *   В начале/конце строки: `  Иванов Иван  `. Должны ли они триммиться?
    *   Множественные пробелы между словами: `Иванов    Иван     Иванович`. Ожидаем схлопывание в один пробел.

• Регистрозависимость: Проверяем, является ли поиск по ФИО регистрозависимым. Поиск по иванов должен находить Иванов.
• Уникальность: Если в системе требуется уникальность ФИО (редко, но бывает), проверяем обработку дублей: Иванов Иван Иванович и Иванов Иван Иванович (с двумя пробелами) — это дубль для системы или нет?
• Интеграция с другими системами (например, с ЭП или документами): Как сохраненное ФИО будет подставляться в шаблон договора? Не разъезжается ли layout при длинном ФИО?

4. Нефункциональные и интеграционные проверки

• Производительность: Ввод и сохранение очень длинного ФИО не должно вызывать заметных задержек.
• Логирование: При ошибке валидации в логах приложения не должно «утекать» полное введенное значение (риск логирования PII-данных).
• Взаимодействие с БД: Проверяем, что ФИО сохраняется в соответствующем поле таблицы без искажений кодировки (проблемы с utf8mb4 для эмодзи, которые в ФИО, конечно, недопустимы, но проверить стоит).
• Валидация на стороне клиента (frontend) и сервера (backend): Обязательно проверяем, что backend валидирует данные независимо от frontend. Отключаем JS в браузере и пытаемся отправить невалидные данные напрямую через API. Backend должен отвергнуть их.

# Пример проверки через curl (API)
curl -X POST https://api.example.com/user \
  -H "Content-Type: application/json" \
  -d '{"full_name": "Test<script>"}' # Backend должен вернуть 400 Bad Request

Ключевые выводы

При проверке поля ФИО я не ограничиваюсь лишь «можно ввести буквы». Я рассматриваю его как конвейер данных: ввод → обработка → хранение → отображение. Мои проверки охватывают:

1. Корректность ввода (валидация).
2. Устойчивость к некорректным данным (безопасность).
3. Соблюдение бизнес-правил (логика).
4. Целостность данных на всём пути (интеграция).

Такой подход позволяет выявить не только поверхностные баги, но и проблемы архитектуры, безопасности и удобства использования.