Когда новичок только заходит в тестирование, он быстро встречает фразу «функциональное тестирование».
Звучит серьёзно. Как будто сейчас нужно открыть терминал, надеть капюшон и начать говорить с компьютером на языке древних разработчиков.
Но на самом деле всё проще.
Функциональное тестирование — это проверка того, что система делает то, что должна делать.
То есть мы проверяем функции продукта:
- можно ли войти в аккаунт,
- создать задачу,
- назначить исполнителя,
- изменить статус,
- оставить комментарий,
- прикрепить файл,
- найти нужную запись,
- получить уведомление.
Если функция задумана — она должна работать.
Если не работает — у нас баг.
Если работает, но не так — тоже баг.
Если работает только после третьего обновления страницы и лёгкой молитвы — ну, вы поняли.
Что такое функциональное тестирование
Функциональное тестирование отвечает на простой вопрос:
Работает ли функция так, как должна?
Представим IT-сервис для работы команды — например, таск-трекер. В нём можно создавать задачи, назначать исполнителей, менять статусы, оставлять комментарии и прикреплять файлы.
Есть функция: создание задачи.
Пользователь нажимает кнопку «Создать задачу», вводит название, описание, выбирает исполнителя и сохраняет.
- - Что должно произойти?
- - Задача должна появиться в списке.
- Название должно сохраниться.
- Описание не должно потеряться.
- Исполнитель должен быть именно тот, кого выбрали.
- Статус должен быть, например, «Новая».
- Если задача не создалась — проблема.
- Если создалась без названия — проблема.
- Если вместо выбранного исполнителя назначился человек, который вообще уволился год назад, — тоже проблема.
А если после одного клика создалось 12 одинаковых задач — это уже не таск-трекер, а генератор паники для менеджера.
Вот это и проверяет функциональное тестирование: соответствует ли поведение системы требованиям и ожиданиям пользователя.
Что такое нефункциональное тестирование
Чтобы лучше понять функциональное тестирование, важно сравнить его с нефункциональным.
Нефункциональное тестирование проверяет не то, что делает система, а то, как она это делает.
Возьмём тот же таск-трекер.
Функционально всё хорошо: пользователь создаёт задачу, задача сохраняется и появляется в списке.
Но есть нюанс: после нажатия кнопки «Создать» система думает 25 секунд.
Формально функция работает.
Но пользователь за это время уже успел забыть, зачем создавал задачу, открыть Telegram, налить чай и нажать кнопку ещё пять раз.
Вот тут вопрос уже не к функциональности, а к качеству работы системы.
Нефункциональное тестирование проверяет, например:
- быстро ли работает система,
- удобно ли ей пользоваться,
- выдерживает ли она много пользователей,
- безопасно ли хранятся данные,
- стабильно ли работает сервис.
То есть функциональное тестирование спрашивает:
«Функция работает?»
А нефункциональное спрашивает:
«А работает она быстро, удобно, безопасно и не как старый ноутбук, который включается только после угроз?»
В этой статье дальше говорим именно про функциональное тестирование. Нефункциональные виды лучше разобрать отдельно.
Основные виды функционального тестирования
Теперь перейдём к видам функционального тестирования, с которыми новичок чаще всего сталкивается на практике.
Важно: мы не будем сюда мешать модульное, интеграционное, системное и приёмочное тестирование. Это отдельная классификация по уровню проверки, и её лучше разбирать в другой статье.
Сейчас говорим именно о том, какие виды функциональных проверок чаще встречаются в работе тестировщика.
1. Smoke-тестирование
Smoke-тестирование — это быстрая проверка самых важных функций системы.
Его задача — понять:
Система вообще жива? Можно тестировать дальше?
Название пришло из инженерной практики: если включили устройство, а из него пошёл дым, дальше проверять уже особо нечего.
В тестировании идея похожая.
Представим, что команда выпустила новую сборку таск-трекера. Перед подробной проверкой тестировщик быстро смотрит:
- можно ли войти в систему,
- открывается ли список задач,
- можно ли создать задачу,
- открывается ли карточка задачи,
- можно ли изменить статус,
- можно ли оставить комментарий.
Если уже вход в систему не работает, нет смысла проверять фильтры, уведомления и прикрепление файлов.
Это как прийти на техосмотр машины, которая не заводится, и начать оценивать удобство подстаканника.
Smoke-тестирование помогает быстро понять: сборка пригодна для дальнейшего тестирования или её нужно сразу возвращать разработчикам.
2. Sanity-тестирование
Sanity-тестирование — это быстрая проверка конкретной изменённой области.
Обычно его проводят после исправления бага или небольшого изменения в системе.
Например, в таск-трекере был баг:
- при смене исполнителя уведомление уходило старому исполнителю, а не новому.
- Разработчик исправил проблему. Теперь тестировщик не проверяет весь сервис целиком. Он смотрит именно изменённую часть:
- меняем исполнителя задачи,
- проверяем, что новый исполнитель получил уведомление,
- проверяем, что задача появилась у него в списке,
- проверяем, что старому исполнителю она больше не назначена.
То есть sanity — это проверка:
«Конкретно это исправление работает? В этой области всё адекватно?»
Sanity можно сравнить с ремонтом дверного замка.
Если мастер починил замок, вы сначала проверяете, открывается ли дверь. Вы не начинаете заодно проверять холодильник, балкон и микроволновку.
Хотя если микроволновка тоже открывается этим ключом — вопросов будет много.
3. Регрессионное тестирование
Регрессионное тестирование проверяет, не сломалась ли старая функциональность после новых изменений.
Это один из самых частых и важных видов функционального тестирования.
Потому что в IT бывает классика:
«Мы просто поправили уведомления, а почему-то перестало сохраняться описание задачи».
И это не шутка. Иногда маленькое изменение в одном месте может сломать что-то совсем рядом. Или даже не рядом. Иногда система ломается так, будто обиделась.
Например, команда добавила новую возможность: теперь к задаче можно прикреплять несколько файлов.
Что нужно проверить?
Не только новую загрузку нескольких файлов, но и старые функции:
- создание задачи,
- редактирование задачи,
- одиночную загрузку файла,
- открытие старых вложений,
- комментарии,
- права доступа к файлам,
- уведомления при изменении задачи.
Зачем?
Потому что новая функция могла случайно повлиять на старую.
Например:
раньше один файл прикреплялся нормально,
после доработки несколько файлов прикрепляются,
но старые вложения перестали открываться.
Пользователь видит файл, нажимает на него, а система говорит:
«Файл не найден».
Хотя вчера он был.
Все его видели.
Он просто ушёл в цифровой туман.
Регрессионное тестирование помогает убедиться: после изменений старые функции продолжают работать правильно.
4. End-to-End тестирование
End-to-End тестирование, или E2E, — это проверка полного пользовательского сценария от начала до конца.
Мы не проверяем одну кнопку отдельно. Мы берём реальный путь пользователя и проходим его полностью.
Например, в баг-трекере полный сценарий может выглядеть так:
- тестировщик создаёт баг,
- заполняет описание,
- прикрепляет скриншот,
- назначает баг на разработчика,
- разработчик переводит задачу в статус «В работе»,
- потом в статус «Исправлено»,
- тестировщик проверяет исправление,
- закрывает баг,
- в истории остаются все изменения.
Это уже похоже на реальную жизнь задачи в команде.
Почему E2E важно?
Потому что отдельные части могут работать нормально, а весь процесс целиком — нет.
Например:
- баг создаётся,
- файл прикрепляется,
- статус меняется,
- комментарии сохраняются,
но после статуса «Исправлено» задача не возвращается тестировщику.
В итоге разработчик думает, что всё сделал.
Тестировщик не видит задачу.
Менеджер думает, что процесс идёт.
Процесс лежит в углу и грустит.
E2E-тестирование помогает проверить, что полный сценарий пользователя работает от начала до конца.
5. API-тестирование
API-тестирование — это проверка функциональности без пользовательского интерфейса.
Для новичка API может звучать пугающе, но идея простая.
Когда пользователь нажимает кнопку в интерфейсе, приложение часто отправляет запрос на сервер.
Например, пользователь нажал «Создать задачу».
Интерфейс отправляет на сервер примерно такой смысловой запрос:
Создай задачу с таким названием, описанием и исполнителем.
Сервер обрабатывает запрос и возвращает ответ:
Задача создана, её ID — 12345.
API-тестирование проверяет именно этот обмен: запросы и ответы.
Например, мы отправляем запрос на создание задачи и ожидаем, что в ответе будут:
ID задачи,название,описание,статус,исполнитель,дата создания.
Если сервер отвечает, что задача создана, но не возвращает ID — это проблема.
Потому что без ID дальше непонятно, как эту задачу открыть, изменить или найти.
API-тестирование полезно ещё и потому, что интерфейс может быть не готов, а серверная логика уже есть.
Дизайнер ещё двигает кнопку на 3 пикселя вправо.
Фронтенд ещё спорит с макетом.
А тестировщик уже может проверять, создаются ли задачи через API.
Что именно можно проверять внутри функционального тестирования
Теперь важный момент.
Smoke, sanity, регрессия, E2E и API — это виды функционального тестирования, которые мы можем применять в работе.
А внутри них мы можем проверять разные части продукта.
Например:
Тестирование форм — ввод и сохранение данных.
В таск-трекере это может быть форма создания задачи или форма создания бага. Проверяем, сохраняется ли название, описание, исполнитель, приоритет, дедлайн и вложения.
Бизнес-логика — правила продукта.
Например, задачу нельзя закрыть, если не заполнено поле результата. Или просроченная задача должна автоматически подсвечиваться.
Права доступа — кто что может делать.
Например, обычный пользователь может создать задачу, но не может удалить проект. И это хорошо. Особенно в пятницу вечером.
Уведомления — кому и когда что приходит.
Например, при назначении задачи уведомление должен получить новый исполнитель, а не вся компания и случайный человек из бухгалтерии.
Поиск и фильтры — как пользователь находит нужное.
Например, если пользователь фильтрует задачи по статусу «Критический баг», система не должна показывать задачи со статусом «Можно когда-нибудь потом».
Работа с файлами — загрузка, отображение и скачивание вложений.
Например, тестировщик прикрепил скриншот к багу, разработчик должен открыть именно этот скриншот, а не пустой файл с названием final_final_2.png.
Работа с данными — сохранение, обновление и отображение информации.
Например, если статус задачи изменился на «Готово», он должен измениться и в карточке задачи, и в общем списке, и в истории изменений.
То есть эти проверки — не отдельная главная классификация, а конкретные области, на которых функциональное тестирование применяется.
Пример, как это выглядит на практике
Допустим, команда делает новую функцию в баг-трекере: теперь при назначении бага на разработчика ему должно приходить уведомление.
Как это можно проверить разными видами функционального тестирования?
Smoke:
проверяем, что баг-трекер открывается, пользователь входит в систему, баг можно создать и назначить.
Sanity:
после исправления уведомлений проверяем именно назначение бага и отправку уведомления нужному разработчику.
Регрессия:
проверяем, что после изменения уведомлений не сломались создание бага, комментарии, смена статуса, вложения и старые уведомления.
E2E:
проходим полный сценарий: тестировщик создаёт баг, назначает разработчика, разработчик получает уведомление, берёт баг в работу, исправляет, тестировщик проверяет и закрывает задачу.
API:
проверяем запрос на назначение исполнителя и ответ сервера: правильно ли изменился исполнитель, создалось ли событие уведомления, вернулись ли корректные данные.
Вот так одна и та же функция может проверяться с разных сторон.
И это нормально. В реальной работе тестирование редко выглядит как идеальная табличка из учебника. Чаще это что-то вроде:
«Так, эту часть поменяли, это могло зацепить соседнюю, тут надо проверить полный сценарий, а тут лучше сразу посмотреть API».
Именно поэтому важно понимать виды тестирования не как сухие термины, а как инструменты.
Зачем новичку это понимать
Новичку может казаться:
«Зачем столько названий? Я же просто хочу тестировать».
Но названия помогают понять, что именно ты сейчас делаешь.
Smoke — быстро проверяешь, жива ли система.
Sanity — проверяешь конкретную изменённую область.
Регрессия — смотришь, не сломалось ли старое.
E2E — проходишь полный путь пользователя.
API — проверяешь работу системы без интерфейса.
А формы, права, уведомления, фильтры, бизнес-логика и файлы — это уже конкретные места, где ты можешь применять эти виды проверок.
Так в голове появляется порядок.
Ты понимаешь:
- что проверяешь,
- зачем проверяешь,
- какой риск закрываешь,
- где может быть баг,
- какой результат ожидаешь.
А это уже не хаос. Это нормальное тестирование.
Итог
Функциональное тестирование проверяет, выполняет ли система свои функции правильно.
Нефункциональное тестирование проверяет, насколько хорошо система это делает: быстро, удобно, стабильно, безопасно.
Основные виды функционального тестирования, которые мы разобрали:
Smoke-тестирование — проверяем, жива ли система после сборки.
Sanity-тестирование — проверяем конкретную изменённую область.
Регрессионное тестирование — убеждаемся, что старое не сломалось после новых изменений.
End-to-End тестирование — проходим полный пользовательский сценарий от начала до конца.
API-тестирование — проверяем работу системы без интерфейса, через запросы и ответы.
А внутри этих видов мы можем проверять формы, бизнес-логику, права доступа, уведомления, поиск, фильтры, загрузку файлов и работу с данными.
Главная мысль простая:
функциональное тестирование — это не просто “потыкать кнопки”, а проверка того, что система делает именно то, что должна делать.
Создал задачу — задача появилась.
Назначил исполнителя — назначился нужный человек.
Изменил статус — статус изменился везде.
Прикрепил файл — файл не исчез в цифровом болоте.
Отправилось уведомление — его получил тот, кто должен.
И чем лучше тестировщик понимает функциональность продукта, тем меньше шансов, что пользователь первым найдёт баг и напишет в поддержку:
«Я ничего не делал, оно само сломалось».
Хотя мы-то знаем: иногда оно действительно само.