Что такое НФТ и как с ними работать

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

Виды требований

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

Глобально, требования делятся на:

Бизнес-требования, которые описывают цели организации и границы проекта, определяемые заказчиками и инвесторами.

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

Функциональные требования — определяют, что именно должно уметь делать ПО, чтобы выполнить бизнес-требования.

Системные требования — включают общие требования к ПО и оборудованию, охватывая все подсистемы.

Бизнес-правила — это внешние ограничения (законы, стандарты, политики), влияющие на функциональность системы.

Нефункциональные требования (НФТ) – представляют собой ограничения, определяющие качественные характеристики системы. Обычно они описываются такими параметрами, как безопасность, производительность и масштабируемость. Эти требования играют важную роль, поскольку обеспечивают соответствие системы ожиданиям пользователей, а также влияют на её конкурентоспособность.

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

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

Классификация нефункциональных требований

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

По уровню применения

• Системные – охватывают всю систему, включая инфраструктуру и взаимодействие компонентов (например, время отклика системы).
• Пользовательские – связаны с взаимодействием пользователей с системой (например, удобство интерфейса).
• Бизнес-уровень – соответствуют целям бизнеса и нормативным требованиям (например, соответствие законодательству).

По свойствам системы

• Производительность – скорость работы системы (например, обработка 5000 запросов в секунду).
• Масштабируемость – способность работать при увеличении нагрузки (например, поддержка роста пользователей без изменения архитектуры).
• Надежность – стабильная работа без сбоев (например, 99.8% доступности в год).
• Безопасность – защита данных и предотвращение несанкционированного доступа (например, шифрование пользовательских данных).
• Удобство использования – интуитивность интерфейса (например, выполнение задачи за 3 клика).
• Мобильность – работа на разных устройствах (например, поддержка Android и iOS).
• Поддержка и сопровождение – возможности диагностики и обслуживания (например, автоматическое оповещение об ошибках).

Примеры НФТ

Масштабируемость: Система должна обеспечивать стабильную работу при увеличении количества активных пользователей с 1 000 до 5 000 без снижения производительности более чем на 10%.

Совместимость: Приложение должно корректно работать в браузерах Chrome, Firefox и Safari последних двух версий.

Производительность: Система должна загружать страницу каталога товаров не более чем за 2 секунды при наличии 10 000 позиций.

Надежность: Система должна сохранять данные пользователя даже при неожиданном отключении сервера и восстанавливать их при следующем запуске.

Переносимость: Система должна быть развернута на облачных платформах AWS, Azure и Google Cloud без модификации кода.

Безопасность: Все пользовательские сессии должны автоматически завершаться после 15 минут бездействия.

Энергоэффективность: Приложение должно минимизировать потребление энергии на мобильных устройствах и не использовать более 5% заряда батареи за час работы.

Удобство использования: Интерфейс мобильного приложения должен поддерживать жесты смахивания для удобной навигации.

Примеры плохих НФТ

❌ Пример: Интерфейс должен быть удобным и интуитивно понятным.

✅ Улучшенный вариант: Пользователь должен уметь выполнить регистрацию за 1 минуту без инструкций.

Комментарий: тут представлена субъективная формулировка без измеримых критериев. В улучшенном варианте добавлено четкое условие проверки.

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

✅ Улучшенный вариант: “Система должна поддерживать 10 000 запросов в секунду при средней нагрузке.”

Комментарий: технически невыполнимое требование. В улучшенной версии добавлены конкретные метрики.

❌ Пример: “Система должна быть безопасной.”

✅ Улучшенный вариант: “Система должна соответствовать стандарту безопасности OWASP Top 10.”

Комментарий: размытая формулировка. Улучшенный вариант ссылается на конкретный стандарт.

❌ Пример: “Система должна шифровать все данные и работать без задержек.”

✅ Улучшенный вариант: “Система должна использовать AES-256 для хранения данных, а критически важные операции — выполняться за ≤ 500 мс.”

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

❌ Пример: “Приложение должно работать одинаково быстро на всех устройствах.”

✅ Улучшенный вариант: “Приложение должно загружаться менее чем за 3 секунды на устройствах с 4 ГБ ОЗУ и выше.”

Комментарий: нереалистичное требование. В улучшенной версии добавлены конкретные условия и метрики.

Для чего QA разбираться в НФТ?

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

Например, НФТ определяют надежность, безопасность, производительность, удобство использования и другие важные аспекты системы. Если эти требования не тестировать, система может работать нестабильно или не соответствовать ожиданиям пользователей.

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

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

НФТ лежат в основе нагрузочного, стрессового, юзабилити, тестирования безопасности, а также тестирования совместимости и доступности. Без понимания этих требований сложно правильно организовать процесс тестирования.

Тестировщик активно участвует в обсуждении требований с аналитиками, разработчиками и заказчиками, что позволяет своевременно выявлять возможные несоответствия и уточнять детали. В команде могут проводиться так называемые "3 Амиго" — совместные сессии, где обсуждаются бизнес-требования, технические аспекты и тестовые сценарии, что способствует лучшему пониманию новой функциональности и минимизирует разночтение документации. Знание НФТ помогает тестировщику не только не упустить важные моменты, которые могли быть не учтены при разработке требований, но и позволяет правильно оценить производительность, безопасность и другие ключевые аспекты, влияющие на качество системы в целом.

Обсудить статью, узнать больше можно в телеграм канале «Тестировщики нужны».