Когда новичок только начинает изучать тестирование, он чаще всего думает о функциональности: нажал кнопку — что-то должно произойти. Отправил форму — данные должны сохраниться. Ввел логин и пароль — система должна пустить пользователя в личный кабинет.
Это всё функциональное тестирование. Оно отвечает на вопрос:
Работает ли функция так, как задумано?
Но в реальных проектах этого мало.
Представим приложение для записи к врачу. Пользователь выбирает специалиста, дату, время и нажимает кнопку «Записаться». С точки зрения функционального тестирования всё может быть хорошо: кнопка работает, запись создаётся, уведомление приходит.
Но что будет, если утром в понедельник в приложение одновременно зайдут тысячи людей?
А если страница записи открывается 15 секунд?
А если пожилому человеку непонятно, куда нажимать?
А если приложение нормально работает на одном телефоне, но ломается на другом?
А если чужой пользователь сможет увидеть медицинские данные другого человека?
Вот здесь начинается нефункциональное тестирование.
Что такое нефункциональное тестирование
Нефункциональное тестирование — это проверка качества работы системы: её скорости, стабильности, безопасности, удобства, совместимости и поведения под нагрузкой.
Если функциональное тестирование проверяет:
«Что система делает?»
то нефункциональное проверяет:
«Как система это делает?»
Например:
Функциональная проверка: пользователь может отправить сообщение в корпоративном мессенджере.
Нефункциональная проверка: сообщение отправляется быстро, интерфейс не зависает, данные не теряются, приложение работает на разных устройствах, а переписка недоступна посторонним.
На практике плохая нефункциональная часть может испортить даже продукт с правильной логикой. Формально функция есть, но пользоваться ей невозможно.
Простой пример
Допустим, команда делает сервис для онлайн-обучения. В нём студент может смотреть уроки, выполнять задания и получать результаты проверки.
С точки зрения функционального тестирования мы проверим:
- открывается ли урок;
- сохраняется ли ответ на задание;
- правильно ли считается результат;
- приходит ли уведомление о проверке;
- видит ли преподаватель работы студентов.
Но нефункциональное тестирование задаст другие вопросы:
- быстро ли открывается видео;
- выдержит ли сервис запуск нового курса, когда одновременно зайдут 10 000 студентов;
- удобно ли пользоваться платформой с телефона;
- не теряются ли ответы, если интернет на секунду пропал;
- защищены ли личные данные студентов;
- одинаково ли работает сервис в разных браузерах.
И это уже совсем другой уровень проверки.
Чем нефункциональное тестирование отличается от функционального
Главное отличие в фокусе.
Функциональное тестирование проверяет конкретные действия и бизнес-логику.
Например:
- можно ли создать задачу;
- можно ли изменить статус;
- правильно ли работает поиск;
- приходит ли уведомление;
- есть ли доступ только у нужных ролей.
Нефункциональное тестирование проверяет качество этих действий.
Например:
- насколько быстро создаётся задача;
- сколько пользователей выдерживает система;
- насколько удобно искать нужную информацию;
- защищены ли данные;
- стабильно ли работает сервис после долгой нагрузки;
- корректно ли всё отображается на разных устройствах.
Можно сказать проще:
Функциональное тестирование — это про правильность.
Нефункциональное тестирование — это про качество использования.
Основные виды нефункционального тестирования
Теперь разберём самые важные виды, с которыми junior QA может столкнуться на практике.
1. Тестирование производительности
Тестирование производительности проверяет, насколько быстро и стабильно работает система.
Здесь нас интересует не просто «работает или нет», а:
- как быстро открывается страница;
- сколько времени занимает запрос;
- не тормозит ли интерфейс;
- не растёт ли время ответа при большом количестве пользователей.
Например, в CRM-системе менеджер открывает карточку клиента. Функционально карточка открывается, данные отображаются. Но если она загружается 12 секунд, это проблема производительности.
Пользователь не будет думать: «Зато функция технически работает».
Он будет думать: «Система тормозит».
Пример проверки
Есть внутренний сервис компании для согласования отпусков. Сотрудник открывает список заявок, выбирает нужную и нажимает «Согласовать».
При тестировании производительности можно проверить:
- сколько секунд открывается список заявок;
- как быстро система сохраняет решение;
- не зависает ли интерфейс при большом количестве записей;
- не увеличивается ли время ответа после нескольких часов работы.
2. Нагрузочное тестирование
Нагрузочное тестирование проверяет, как система ведёт себя при ожидаемой или повышенной нагрузке.
Например, команда знает, что сервисом обычно пользуются 2 000 человек в день, а в пиковые часы одновременно может быть 500 активных пользователей.
Задача тестирования — понять, выдержит ли система такую нагрузку.
Пример: приложение для записи на корпоративное обучение. Компания открывает регистрацию на новый курс, и в первые минуты туда заходят сотни сотрудников. Важно проверить, не упадёт ли сервис, не начнут ли пропадать заявки и не станет ли всё работать слишком медленно.
Нагрузочное тестирование помогает ответить на вопросы:
- сколько пользователей выдерживает система;
- когда начинается деградация;
- какие запросы самые тяжёлые;
- где появляется узкое место;
- как система ведёт себя на пике активности.
3. Стресс-тестирование
Стресс-тестирование похоже на нагрузочное, но цель здесь другая.
Если нагрузочное тестирование проверяет систему в ожидаемых условиях, то стресс-тестирование проверяет её на пределе.
Мы специально создаём ситуацию, где нагрузка выше нормы, чтобы понять:
- когда система сломается;
- как именно она сломается;
- восстановится ли после сбоя;
- не потеряются ли данные;
- покажет ли пользователь понятную ошибку.
Например, сервис электронного документооборота обычно обрабатывает 1 000 документов в час. При стресс-тестировании можно дать ему 5 000 или 10 000 документов и посмотреть, что произойдёт.
Хороший результат — это не обязательно «система выдержала всё». Иногда важнее, чтобы она сломалась предсказуемо: не потеряла данные, не показала пользователям хаос и смогла восстановиться.
4. Тестирование стабильности
Тестирование стабильности проверяет, как система работает долгое время без перерыва.
Иногда приложение может нормально вести себя первые 10 минут, но начать тормозить через несколько часов. Например, из-за утечек памяти, накопления ошибок или проблем с соединениями.
Пример: операторская система поддержки клиентов работает весь день. Сотрудники открывают обращения, пишут ответы, прикрепляют файлы, меняют статусы. Важно понять, не начнёт ли система зависать ближе к концу рабочего дня.
При тестировании стабильности смотрят:
- не увеличивается ли потребление памяти;
- не растёт ли время ответа;
- не появляются ли ошибки после длительной работы;
- не падает ли сервис без видимой причины.
5. Тестирование удобства использования
Тестирование удобства использования, или usability testing, проверяет, насколько пользователю понятно и удобно работать с продуктом.
Здесь важно не только «можно ли выполнить действие», но и насколько легко это сделать.
Например, в приложении для управления задачами пользователь хочет создать новую задачу. Функция работает, кнопка есть, задача создаётся. Но если кнопка спрятана в непонятном меню, форма перегружена полями, а ошибка написана техническим языком, пользователь будет страдать.
Что можно проверять:
- понятно ли, куда нажимать;
- легко ли найти нужное действие;
- не перегружен ли экран;
- понятны ли тексты ошибок;
- логично ли расположены элементы;
- может ли новый пользователь разобраться без инструкции.
Пример плохого сообщения:
Ошибка 400: invalid request payload
Пример более понятного сообщения:
Не удалось сохранить задачу. Проверьте, что заполнены название и срок выполнения.
Система может быть функционально правильной, но неудобной. И это тоже дефект качества.
6. Тестирование безопасности
Тестирование безопасности проверяет, защищены ли данные и функции системы от неправильного или злонамеренного доступа.
Для junior QA это не всегда глубокий пентест или сложная работа с уязвимостями. На базовом уровне можно проверять простые, но важные вещи.
Например:
- может ли обычный пользователь открыть страницу администратора;
- можно ли увидеть чужие данные, поменяв ID в ссылке;
- скрываются ли пароли;
- завершается ли сессия после выхода;
- нельзя ли выполнить действие без авторизации;
- не отображаются ли технические данные в ошибках.
Пример: в системе управления задачами пользователь открывает свою задачу по ссылке:
/tasks/125
Если он меняет адрес на:
/tasks/126
и видит чужую задачу, это серьёзная проблема безопасности и прав доступа.
Даже если сама функция просмотра задач работает, система нарушает важное нефункциональное требование — безопасность.
7. Тестирование совместимости
Тестирование совместимости проверяет, как система работает в разных окружениях.
Например:
- в разных браузерах;
- на разных операционных системах;
- на разных устройствах;
- при разных разрешениях экрана;
- с разными версиями приложения;
- с разными настройками языка или региона.
Простой пример: веб-сервис отлично работает в Chrome на большом мониторе, но в Safari на iPhone кнопка «Сохранить» уезжает за экран. Функция есть, логика правильная, но пользователь не может нормально ей воспользоваться.
Что можно проверять:
- корректно ли отображается интерфейс;
- не ломается ли вёрстка;
- работают ли кнопки и формы;
- нет ли проблем с адаптивностью;
- одинаково ли ведут себя основные сценарии.
Для junior QA это один из самых понятных видов нефункционального тестирования, потому что многие проблемы можно найти вручную.
8. Тестирование надёжности
Тестирование надёжности проверяет, насколько система способна работать без сбоев и сохранять корректное состояние.
Например, пользователь отправляет отчёт, и в этот момент кратковременно пропадает интернет. Что произойдёт?
Плохой вариант:
- отчёт потерялся;
- пользователь не понял, что произошло;
- система показала пустой экран;
- повторная отправка создала дубликат.
Хороший вариант:
- система показала понятное сообщение;
- данные сохранились в черновик;
- пользователь может повторить отправку;
- дубликаты не создаются.
Надёжность особенно важна там, где потеря данных болезненна: документы, заявки, медицинские данные, обучение, финансы, корпоративные системы.
9. Тестирование восстановления после сбоев
Этот вид тестирования проверяет, может ли система восстановиться после ошибки, падения или отключения части инфраструктуры.
Например:
- сервер временно недоступен;
- база данных отвечает медленно;
- пропало соединение с внешним сервисом;
- приложение было закрыто во время операции;
- пользователь потерял интернет.
Допустим, сотрудник загружает файл в систему документооборота. На середине загрузки соединение обрывается. Нужно проверить:
- увидит ли пользователь понятное сообщение;
- можно ли повторить загрузку;
- не появится ли битый файл;
- не создастся ли пустая запись;
- не зависнет ли статус документа.
Здесь важно не только предотвратить сбой, но и сделать поведение системы предсказуемым.
10. Тестирование доступности
Тестирование доступности проверяет, могут ли пользоваться системой люди с разными ограничениями.
Например:
- достаточно ли контрастный текст;
- можно ли пользоваться сайтом с клавиатуры;
- есть ли подписи у важных элементов;
- понятны ли ошибки;
- не завязано ли всё только на цвет;
- можно ли увеличить масштаб без поломки интерфейса.
Пример: в системе поле подсвечивается красным, если заполнено неправильно. Но если рядом нет текста ошибки, пользователь с нарушением восприятия цвета может не понять, что произошло.
Плохой вариант:
Поле просто стало красным.
Хороший вариант:
Поле подсвечено, и рядом написано: “Введите дату в формате ДД.ММ.ГГГГ”.
Доступность — это не «дополнительная красота», а часть качества продукта.
Какие дефекты можно найти при нефункциональном тестировании
Нефункциональные дефекты часто выглядят не как «кнопка не работает», а как проблемы качества.
Например:
- страница открывается слишком долго;
- система зависает при большом количестве данных;
- интерфейс ломается на мобильном экране;
- пользователь видит чужие данные;
- ошибка написана непонятным техническим текстом;
- приложение не восстанавливается после потери соединения;
- сервис падает при резком росте нагрузки;
- форма неудобная и пользователь постоянно ошибается;
- данные теряются после сбоя.
Такие проблемы могут быть не менее критичными, чем обычные функциональные баги.
Иногда даже более критичными.
Пользователь может простить мелкую ошибку в интерфейсе. Но если система медленная, неудобная или небезопасная, доверие к продукту быстро пропадает.
Что важно понимать junior QA
Junior QA не обязан сразу уметь проводить сложное нагрузочное тестирование, писать скрипты для performance-тестов или искать глубокие уязвимости безопасности.
Но junior должен понимать саму идею:
качество продукта — это не только работающие функции.
На старте достаточно научиться замечать простые вещи:
- долго загружается страница;
- неудобно выполнить действие;
- ошибка непонятна пользователю;
- интерфейс ломается на другом экране;
- после потери интернета данные ведут себя странно;
- пользователь может попасть туда, куда не должен;
- система плохо работает с большим количеством записей.
Это уже хороший первый шаг к пониманию нефункционального тестирования.
Итог
Нефункциональное тестирование проверяет качество системы: скорость, стабильность, безопасность, удобство, совместимость, надёжность и поведение в сложных условиях.
Функциональное тестирование отвечает на вопрос:
«Работает ли функция?»
Нефункциональное тестирование отвечает на вопрос:
«Можно ли этим нормально, безопасно и стабильно пользоваться?»
Именно поэтому в реальной разработке важны оба подхода. Можно сделать продукт, где все кнопки формально работают, но пользоваться им будет невозможно. А можно заранее проверить не только функции, но и качество их работы — и сделать систему, которой действительно доверяют.