Функциональное Тестирование — это процесс контроля качества (QA), целью которого является проверка того, что программное обеспечение работает в соответствии с функциональными требованиями.

Ключевая Цель

Основная цель — валидация (проверка) бизнес-логики приложения. Функциональное тестирование проверяет, что каждая функциональность (фича) продукта работает правильно, как это описано в техническом задании (ТЗ) или пользовательских историях (User Stories).

Что конкретно проверяется

Функциональное тестирование фокусируется на “позитивных” и “негативных” сценариях.

Позитивные Сценарии (Happy Path)

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

Пример

Тестирование формы входа.

Действие: Пользователь вводит правильный, существующий логин и правильный пароль.

Ожидаемый результат: Система успешно аутентифицирует пользователя и перенаправляет его в личный кабинет.

Негативные Сценарии

Проверка того, что система корректно обрабатывает неожиданное поведение и некорректные данные. Система не должна “сломаться”.

Пример

Тестирование той же формы входа

  • Действие 1: Ввести правильный логин и неправильный пароль.
    Ожидаемый результат 1: Система показывает понятное сообщение об ошибке (“Неверный логин или пароль”), не пускает пользователя и не падает.
  • Действие 2: Оставить поле “логин” пустым и нажать “Войти”.
    Ожидаемый результат 2: Система показывает ошибку валидации (“Поле ‘логин’ не может быть пустым”).

Корнер кейсы

Проверка граничных значений — маловероятных или экстремальных сценариев.

Пример

Тестирование поля для загрузки аватара.

  • Ограничение: Максимальный размер файла — 5 МБ.
  • Действие: Попытаться загрузить файл размером 5.1 МБ (негативный) и файл размером 4.9 МБ (позитивный).

Участники

QA-инженеры (Тестировщики), как вручную (Manual QA), так и с помощью автотестов (QA Automation).

Артефакты Тестирования:

  • Тест-кейс (Test Case): Самый важный документ. Это детальная пошаговая инструкция для проверки одной конкретной функции.

    • Структура:

      1. ID: Уникальный номер.

      2. Название: Что проверяем (например, “Вход с корректными данными”).

      3. Предусловия: Что должно быть сделано до начала (например, “Пользователь зарегистрирован”).

      4. Шаги: “1. Открыть /login”, “2. Ввести ‘user@test.com’…”, “3. Нажать ‘Войти’“.

      5. Ожидаемый результат: “Пользователь перенаправлен на /dashboard”.

  • Баг-репорт (Bug Report): Документ, который создается, если фактический результат не совпадает с ожидаемым результатом. Это отчет об ошибке для разработчиков.

Этап в ЖЦ

Функциональное тестирование проводится на тестовой среде (Test Environment), где находится “сборка” (build) — версия приложения, готовая к проверке.

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

Заключение

Что дальше?

➡️ Разберём что такое дизайн ревью и зачем оно нужно

НазадДалее