Виды тестирования: функциональное, регрессионное, нефункциональное
Мы продолжаем погружение в мир качества веб-приложений. На прошлом этапе мы разобрали семь фундаментальных принципов, которые помогают расставлять приоритеты. Теперь применим эти знания на практике и поймем, на какие «слои» разделяются проверки.
В профессиональной среде QA-инженеры классифицируют тесты, чтобы точно знать, какую характеристику системы они проверяют. Это помогает находить критические ошибки быстрее и не тратить время команды впустую. Все проверки делятся на три группы, которые представлены на Схеме 1.
Функциональное тестирование: что делает система
Функциональное тестирование проверяет, выполняет ли приложение свои задачи. Мы смотрим на систему глазами пользователя: может ли он зарегистрироваться, купить товар или отправить сообщение.
Возьмем форму входа в личный кабинет. Здесь мы проверяем логику:
- Пустит ли система пользователя с верным паролем?
- Появится ли ошибка при вводе неверных данных?
- Придет ли письмо для восстановления доступа?
Если кнопка «Войти» нажимается, но ничего не происходит — это функциональный дефект. Мы проверяем, что делает программа, не оценивая пока её скорость или дизайн.
Нефункциональное тестирование: как работает система
Когда функции работают, пора проверить комфорт и надежность. Нефункциональное тестирование оценивает характеристики, которые не связаны с бизнес-логикой напрямую, но определяют успех продукта.
Middle QA-инженер фокусируется на четырех направлениях:
- Производительность (Performance): выдержит ли сайт наплыв 10 000 покупателей во время распродажи? 📉
- Удобство использования (Usability): логично ли расположены кнопки и не слишком ли мелкий шрифт?
- Безопасность (Security): защищены ли данные пользователей от взлома? 🛡️
- Доступность (Accessibility): смогут ли сайтом пользоваться люди с ограничениями по зрению или моторике?
Функционально сайт может быть идеален, но если страница грузится 15 секунд, пользователи уйдут к конкурентам. Нефункциональные проверки — это борьба за лояльность клиента.
Регрессионное тестирование: стратегия «не навреди»
Представьте: разработчики добавили на сайт оплату через СБП. Вы проверили — всё работает. Но не сломалась ли при этом обычная оплата картой?
Для этого проводят регрессионное тестирование. Это проверка уже протестированных частей приложения после изменений в коде. Цель — убедиться, что новые правки не вызвали «регресс» (откат назад) в качестве старых функций.
Не путайте регресс с повторным тестированием (Re-testing). Разница видна в таблице:
| Характеристика | Повторное тестирование (Re-testing) | Регрессионное тестирование |
|---|---|---|
| Цель | Подтвердить, что баг исправлен. | Убедиться, что исправление не сломало соседние модули. |
| Объект | Конкретное место, где была ошибка. | Смежные функции или всё приложение. |
| Когда | Сразу после исправления бага. | После успешного Re-testing, перед релизом. |
В современных компаниях регрессионные проверки часто автоматизируют, чтобы освободить инженеров от рутины. 🤖
Практический кейс: выбор вида тестирования
В интернет-магазине обновили поиск. Распределяем усилия:
- Функциональное: ищем товары по названию и артикулу. Проверяем, выдает ли поиск нужный результат.
- Нефункциональное: замеряем время ответа (не более 2 секунд) и проверяем верстку на смартфонах.
- Регрессионное: проверяем, работают ли фильтры по цене и корзина, которые мы не трогали.
Пропуск любого этапа — это риск выпустить сырой продукт.
Мы научились классифицировать тесты по назначению. Но на каком этапе и над какими частями кода проводятся эти проверки? В следующей теме разберем уровни тестирования — от маленьких фрагментов кода до всей системы в сборе. Это поможет понять, кто в команде отвечает за каждый этап качества.