Ответ

История вопроса:

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

Проблема:

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

Решение:

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

Ключевые особенности:

• Требуют чёткого формирования критериев приёмки.
• Результаты оценки часто субъективны, потому важна аргументированность отчётов.
• Не все подобные дефекты допустимы перед релизом — часть критичны.

Вопросы с подвохом.

Все нефункциональные дефекты должен фиксировать баг-репортом тестировщик?

Не всегда. Если проблема субъективна, иногда ее достаточно обсудить с командой и зафиксировать как улучшение (feature request).

Должен ли тестировщик сам ставить метрики по производительности?

Только если они не прописаны в требованиях или ТЗ, иначе опираться на них.

Обязательно ли наличие специального ПО или инструментов для нефункционального тестирования?

Нет, базовые проверки вполне возможны вручную (например, замер времени вручную, анализ доступности по чек-листу).

Типовые ошибки и анти-паттерны

• Игнорирование нефункциональных критериев.
• Субъективные отчеты без измеримых доказательств.
• Слишком общие или размытые названия и описания багов.

Пример из жизни

Негативный кейс

Тестировщик заметил, что страница каталога грузится дольше 10 секунд, но не завёл баг, решив, что “это наверное у всех так”.

Плюсы:

• Не засыпал команду спорными тикетами.

Минусы:

• Снижен user experience, клиенты разочарованы, руководству о проблеме узнали из жалоб.

Позитивный кейс

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

Плюсы:

• Команда получила объективное описание проблемы и смогла быстро ее диагностировать.

Минусы:

• На оформление таких багов уходит больше времени.