Что проверял при верификации на проекте

Отличный вопрос. Верификация в тестировании — это процесс проверки, что мы создаем продукт правильно, то есть он соответствует техническим спецификациям, требованиям и дизайну. Это глубокая проверка соответствия на уровне функций, кода и компонентов. В моей практике при верификации я всегда действую на нескольких уровнях, от самых базовых до комплексных.

1. Верификация Функциональных Требований (Functional Verification)

Это основа. Я проверяю, что каждая заявленная функция реализована и работает в точности так, как описано в техническом задании, пользовательских историях или спецификациях.

• Корректность основных и граничных сценариев: Функция отрабатывает на «счастливом пути» и на краях допустимых значений (boundary values).
• Соответствие спецификации: Все поля, валидация, бизнес-правила, вычисления (например, итоговая сумма заказа) строго следуют документации.

  // Пример верификации расчета скидки по спецификации:
  // "Скидка 10% для заказов от 5000 руб."
  public void testDiscountCalculation() {
      Order order = new Order(5000);
      double expectedDiscount = 5000 * 0.10; // 500.0 согласно спецификации
      double actualDiscount = order.calculateDiscount();
  
      assertEquals(expectedDiscount, actualDiscount, 0.01,
              "Скидка 10% для суммы 5000 рассчитана неверно");
  }
  

• Взаимодействие с данными: CRUD-операции (создание, чтение, обновление, удаление данных) выполняются корректно, данные сохраняются в БД в ожидаемом формате и без искажений.

2. Верификация Нефункциональных Требований и Качественных Атрибутов

Важно проверить не только что делает система, но и как.

• Валидация и обработка ошибок: При вводе некорректных данных система возвращает четкие, понятные, задокументированные сообщения об ошибках, а не падает или не «зависает».
• Производительность на уровне компонента: Например, проверка времени ответа отдельного API-метода или отрисовки сложного UI-виджета. Использую профилировку или простые замеры.

  // Пример замера времени отрисовки компонента (концепт)
  console.time('renderComponent');
  renderComplexChart(data);
  console.timeEnd('renderComponent'); // Должно быть < 100мс согласно требованию
  

• Совместимость (Compatibility): Проверяю, что компонент или функция корректно работают на целевых браузерах, разрешениях экрана, версиях ОС или мобильных устройств (на данном этапе — в рамках заявленных требований).
• Юзабилити на уровне компонента: Соответствие макетам (UI/UX), корректность состояний (hover, active, disabled), читаемость текста, доступность базовых атрибутов (например, alt для изображений).

3. Верификация Интеграционных Точек

Даже проверяя отдельный компонент, я всегда помню о его связях.

• API-контракты: Ответы эндпоинтов строго соответствуют Swagger/OpenAPI спецификации — статус-коды, схема JSON (поля, типы данных, обязательность), заголовки.

  # Пример проверки API-контракта с помощью curl и jq
  curl -s $API_URL/orders/123 | jq '. | has("id", "status", "total")'
  # Возвращает true/false, подтверждая наличие обязательных полей
  

• Взаимодействие с внешними сервисами и БД: Проверяю, что данные передаются в смежные системы в правильном формате, а ошибки от этих систем корректно обрабатываются (например, падение платежного шлюза не приводит к потере заказа).

4. Верификация Кода и Безопасности (Code-Centric Verification)

Это то, что тесно связывает QA с разработкой.

• Чтение и ревью кода (Code Review): Участвую в ревью, обращая внимание на потенциальные уязвимости (SQL-инъекции, XSS), обработку исключений, корректность ключевых бизнес-алгоритмов.
• Анализ логов и мониторинга: После деплоя проверяю логи приложения на предмет ошибок (ERROR, WARN), которые не были видны на UI. Убеждаюсь, что метрики (например, количество успешных операций) собираются.
• Статический анализ (SAST): Использование инструментов (например, SonarQube) для автоматической проверки кода на уязвимости и запахи (code smells) — часть процесса верификации качества кодовой базы.

5. Верификация Документации и Процессов

Продукт — это не только код.

• Актуальность документации: Соответствуют ли README, инструкции по развертыванию, Swagger-документация текущей реализации. Нередко нахожу расхождения.
• Сценарии миграции данных: Если в релизе есть миграции БД, тщательно проверяю их на тестовом стенде — корректность скриптов, отката (rollback), целостность данных после применения.
• Соответствие процессам: Была ли выполнена необходимая для задачи работа: написан ли юнит-тест, обновлена ли документация API, прошел ли код статический анализ.

Заключение: Моя верификация на проекте — это многоуровневый инженерный процесс. Он начинается с формального соответствия требованиям, но неизбежно углубляется в качество кода, надежность интеграций, удобство использования и сопровождения. Ключевая цель — выявить дефекты как можно раньше, на этапе, когда их исправление наименее затратно, и гарантировать, что в основную ветку разработки попадает максимально качественный и проверенный код.