Виды тестирования: функциональное, регрессионное и приёмочное — в чём разница

Зачем это знать?

Представьте, что вы открываете новый ресторан. Перед запуском вы проверяете: правильно ли готовятся блюда по рецепту (это одна проверка), не испортилось ли старое меню после того, как повар добавил новое блюдо (другая проверка), и доволен ли первый гость, которого вы пригласили попробовать всё перед открытием (третья проверка).

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

💡 Вид тестирования — это способ организовать проверку программы с определённой целью. Разные виды отвечают на разные вопросы: «работает ли это вообще?», «не сломалось ли то, что работало раньше?», «готов ли продукт для пользователя?»

Понимание разницы между видами тестирования — это фундамент профессии QA-инженера. Без него невозможно грамотно составить план проверок, расставить приоритеты и объяснить команде, что и зачем вы тестируете.

Теория

Шаг 1. Что такое «программное обеспечение» и «функция»

Прежде чем идти дальше, договоримся о терминах.

🔑 Программное обеспечение (ПО, или «программа») — это набор инструкций, которые говорят компьютеру или телефону, что делать. Браузер, мессенджер, онлайн-банк — всё это программное обеспечение.

🔑 Функция — конкретное действие, которое умеет выполнять программа. Например, «войти в аккаунт», «перевести деньги», «добавить товар в корзину».

🔑 Баг (bug) — ошибка в программе, из-за которой она ведёт себя не так, как ожидается. Слово пришло из английского и буквально означает «жук»: по легенде, в старые компьютеры однажды залез настоящий жук и сломал работу машины.

Теперь можно разбирать виды тестирования.

Шаг 2. Функциональное тестирование

Что это?

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

Аналогия из жизни. Вы купили новый холодильник. Вы открываете дверцу — она должна открываться. Включаете — он должен охлаждать. Нажимаете кнопку «быстрая заморозка» — температура должна снизиться. Вы проверяете каждую функцию по отдельности. Это и есть функциональное тестирование.

Что именно проверяется?

• Поля ввода: можно ли ввести логин и пароль?
• Кнопки: срабатывают ли они при нажатии?
• Результаты: отображается ли правильный ответ после действия пользователя?
• Граничные случаи: что будет, если ввести неверный пароль? Слишком длинное имя? Ничего не ввести?

Ключевой вопрос функционального тестирования

«Делает ли программа то, что должна делать?»

Пример из практики

Допустим, вы тестируете форму регистрации на сайте. Требование звучит так:

«Если пользователь вводит корректный email и пароль длиной не менее 8 символов, нажимает кнопку "Зарегистрироваться" — система создаёт аккаунт и показывает сообщение "Регистрация прошла успешно"».

Ваша задача — проверить, выполняется ли это требование. Вы заходите на страницу, вводите данные и смотрите на результат.

Шаг 3. Регрессионное тестирование

Что это?

🔑 Регрессионное тестирование — это проверка того, что после внесения изменений в программу (добавления новой функции, исправления бага) всё остальное продолжает работать так же, как раньше.

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

Аналогия из жизни. Сантехник починил кран на кухне. Вы радуетесь, но потом проверяете: а не потёк ли теперь кран в ванной? Не упало ли давление воды в душе? Изменение в одном месте может неожиданно сломать другое — и регрессионное тестирование как раз ловит такие ситуации.

Почему это важно?

Программы устроены сложно: разные части кода связаны между собой. Разработчик исправил ошибку в модуле оплаты — и внезапно перестала работать корзина. Такое случается регулярно, и без регрессионного тестирования эти проблемы легко пропустить.

Ключевой вопрос регрессионного тестирования

«Не сломало ли новое изменение то, что работало раньше?»

Когда проводится?

Регрессионное тестирование запускают каждый раз, когда в программу вносятся изменения:

• добавлена новая функция
• исправлен баг
• обновлена библиотека (набор готового кода, который использует программа)
• изменён дизайн

💡 Именно регрессионное тестирование чаще всего автоматизируют — то есть поручают компьютеру выполнять повторяющиеся проверки автоматически. Это одна из главных причин, зачем нужна QA-автоматизация.

Шаг 4. Приёмочное тестирование

Что это?

🔑 Приёмочное тестирование — это финальная проверка программы перед тем, как её передают пользователям. Цель — убедиться, что продукт соответствует ожиданиям заказчика и реальным потребностям людей.

Аналогия из жизни. Вы заказали торт на свадьбу. Кондитер приносит его за день до события. Вы смотрите: тот ли это вкус, тот ли дизайн, правильный ли размер? Если всё устраивает — вы «принимаете» торт. Если нет — просите переделать. Это и есть приёмка.

Кто проводит приёмочное тестирование?

Здесь возможны два варианта:

🔑 UAT (User Acceptance Testing) — вид приёмочного тестирования, при котором проверяется, что система удовлетворяет бизнес-требованиям и удобна для конечного пользователя. Аббревиатура UAT пришла из английского языка и широко используется в русскоязычной IT-среде.

Ключевой вопрос приёмочного тестирования

«Готов ли продукт к тому, чтобы им пользовались реальные люди?»

Шаг 5. Сравниваем все три вида

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

🔑 Релиз — это выпуск новой версии программы для пользователей. Как выпуск нового альбома у музыканта — только вместо музыки здесь обновлённое приложение.

Шаг 6. Как эти виды связаны между собой?

Важно понять: эти три вида тестирования не заменяют, а дополняют друг друга. Вот как они выстраиваются в жизненный цикл разработки:

Новая функция готова
        ↓
[Функциональное тестирование]
Проверяем: работает ли новая функция?
        ↓
Функция работает. Добавляем в программу.
        ↓
[Регрессионное тестирование]
Проверяем: не сломали ли мы что-то старое?
        ↓
Всё работает. Готовимся к выпуску.
        ↓
[Приёмочное тестирование]
Проверяем: готов ли продукт для пользователей?
        ↓
Получаем одобрение. Выпускаем релиз.

Если на каком-то шаге находится баг — программисты его исправляют, и цикл проверок запускается снова.

Разбор конкретного примера

Давайте пройдём через все три вида тестирования на одном реальном сценарии.

Ситуация: Команда разрабатывает мобильное приложение для оплаты коммунальных услуг. Добавили новую функцию — оплата по QR-коду.

Функциональное тестирование новой функции

Мы проверяем, работает ли оплата по QR-коду согласно требованиям.

Тест-кейс №1: Успешная оплата по QR-коду
-----------------------------------------
Предусловие: пользователь авторизован, на счёте есть средства

Шаг 1: Открыть экран "Оплата"
Шаг 2: Нажать кнопку "Сканировать QR-код"
Шаг 3: Навести камеру на корректный QR-код квитанции
Шаг 4: Нажать кнопку "Оплатить"

Ожидаемый результат:
- Появляется экран подтверждения с суммой
- После подтверждения — сообщение "Оплата прошла успешно"
- В истории операций появляется новая запись

Фактический результат: [заполняется тестировщиком]
Статус: ПРОЙДЕН / ПРОВАЛЕН

🔑 Тест-кейс — это подробное описание одной проверки: что делаем шаг за шагом и что должно произойти в итоге. Это как рецепт: без точных шагов результат непредсказуем.

Регрессионное тестирование после добавления функции

Новая функция добавлена в приложение. Теперь проверяем, не сломалось ли что-то, что работало раньше.

Регрессионный список проверок (фрагмент):
-----------------------------------------
✓ Авторизация по логину и паролю
✓ Оплата по номеру счёта (старый способ)
✓ Просмотр истории платежей
✓ Пополнение баланса
✓ Выход из аккаунта
✓ Работа в офлайн-режиме (без интернета)

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

Приёмочное тестирование перед выпуском

На этом этапе приглашают нескольких реальных пользователей или заказчика. Они работают с приложением как обычные люди — без технических инструкций.

Сценарий приёмочного тестирования:
-----------------------------------
Пользователю дают задание:
"Оплатите счёт за электричество за прошлый месяц
 любым удобным способом."

Тестировщик наблюдает и фиксирует:
- Смог ли пользователь найти нужный раздел самостоятельно?
- Возникли ли вопросы или затруднения?
- Завершил ли он оплату без посторонней помощи?
- Остался ли доволен процессом?

Если пользователь путается или не может выполнить задание — это сигнал: продукт ещё не готов к выпуску.

Практика

Упражнение 1. Определите вид тестирования

Прочитайте каждую ситуацию и определите, какой вид тестирования описывается: функциональное, регрессионное или приёмочное.

1. Разработчики исправили ошибку в модуле поиска товаров в интернет-магазине. QA-инженер заново проверяет корзину, оформление заказа и личный кабинет — чтобы убедиться, что они не пострадали.

2. В новом приложении для заказа такси тестировщик проверяет: отображается ли карта, можно ли выбрать точку назначения, рассчитывается ли стоимость поездки и появляется ли кнопка «Вызвать водителя».

3. Перед запуском нового сервиса доставки еды компания даёт доступ к приложению 50 добровольцам, которые делают реальные заказы и оставляют отзывы о своём опыте.

4. После добавления тёмной темы в мобильное приложение тестировщик запускает полный список проверок: вход, регистрация, профиль, уведомления, оплата.

📝 Ответы: 1 — регрессионное; 2 — функциональное; 3 — приёмочное; 4 — регрессионное.

Упражнение 2. Составьте мини тест-кейс для функционального тестирования

Возьмите любое простое приложение на вашем телефоне или компьютере (например, калькулятор, приложение погоды или заметки). Выберите одну функцию и опишите проверку по образцу:

Тест-кейс: [название]
-----------------------
Что проверяем: [функция]

Шаг 1: ...
Шаг 2: ...
Шаг 3: ...

Ожидаемый результат: ...

Не нужно никакого специального инструмента — просто текстовый файл или бумага. Главное — описать чёткие шаги и то, что должно произойти.

Упражнение 3. Найдите «регрессию» в жизни

Вспомните или придумайте ситуацию из обычной жизни (не из IT), когда исправление одной проблемы привело к появлению другой. Опишите её в 3–5 предложениях и объясните, как это похоже на регрессионный баг в программе.

Пример-подсказка: Вы переставили мебель в комнате, чтобы лучше падал свет на рабочий стол. В итоге стало неудобно открывать дверь шкафа.

Упражнение 4. Расставьте по порядку

Ниже перечислены действия из процесса выпуска нового мобильного приложения. Расставьте их в правильном логическом порядке (от 1 до 6):

• Группа из 20 реальных пользователей тестирует приложение и даёт обратную связь
• Разработчик пишет код для функции «Избранное»
• QA-инженер проверяет, что функция «Избранное» работает согласно требованиям
• Приложение выходит в публичный доступ
• QA-инженер повторно проверяет все существующие функции приложения
• Команда получает одобрение заказчика на выпуск

📝 Правильный порядок: 2 → 3 → 5 → 6 → 1 → 4

Главные выводы

• 🧪 Функциональное тестирование проверяет, работает ли конкретная функция так, как описано в требованиях. Ключевой вопрос: «Делает ли программа то, что должна?»

• 🔄 Регрессионное тестирование проверяет, что изменения в коде не сломали то, что работало раньше. Ключевой вопрос: «Не стало ли хуже после изменений?»

• ✅ Приёмочное тестирование — финальная проверка перед выпуском, с точки зрения реального пользователя. Ключевой вопрос: «Готов ли продукт для людей?»

• Эти три вида тестирования не конкурируют, а работают вместе: сначала проверяем новое, затем убеждаемся, что старое цело, затем получаем «добро» от пользователей.

• Регрессионное тестирование — одна из главных причин, зачем автоматизируют проверки: делать одни и те же проверки вручную снова и снова — долго и дорого.

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

🚀 Следующий шаг. Теперь, когда вы понимаете, что тестировать, следующий урок расскажет, как это делать системно — вы научитесь писать тест-кейсы и чек-листы, которые не дадут пропустить важные проверки.