Ответ.

Нефункциональное тестирование — это проверка системы не только с точки зрения выполнения бизнес-функций, но и по параметрам удобства использования (usability), производительности, безопасности, адаптивности и доступности (accessibility).

История вопроса: Если в начале развития тестирования упор делался исключительно на «работает/не работает», то с ростом конкуренции и требований к качеству продукта стали обращать внимание и на сопутствующие параметры — удобство, скорость работы, доступность для людей с ограниченными возможностями. Это повлияло на развитие нефункционального тестирования.

Проблема: Тестировщики часто не знают, как формализовать и оценить нефункциональные параметры вручную. Возникает субъективность: то, что удобно одному пользователю, неудобно другому. Отсутствие четких чек-листов и критериев только усугубляет ситуацию.

Решение: Тестировщик должен:

• Использовать стандарты и рекомендации, такие как WCAG для accessibility или ISO 9241 для usability.
• Применять специальные инструменты (например, цветовой анализатор для проверки контраста текста и фона, симулятор screen-reader для проверки доступности).
• Разрабатывать чек-листы для проверки user experience, навигации, читаемости элементов и т.д.
• Привлекать реальных пользователей с разным опытом для user-testing.

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

• Работа с «живыми сценариями» пользователя, а не только по готовым тест-кейсам.
• Необходимость документировать найденные нефункциональные проблемы максимально конкретно.
• Умение использовать сторонние инструменты для анализа (например, Lighthouse, Axe, NVDA, JAWS, Color Contrast Analyzer).

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

Можно ли обойтись без ручного тестирования usability, если используются автоматизированные тесты?

Нет. User experience сильно субъективен, и многие аспекты могут быть выявлены только при ручном анализе или обращении к реальным пользователям.

Достаточно ли проверить доступность (accessibility) только с помощью автоматических сканеров?

Нет. Автоматические проверки выявляют, как правило, лишь 20–30% проблем. Остальные — только с помощью ручного взаимодействия: проверки с навигацией клавиатурой, чтения скрин-ридером и т.п.

Нужно ли тестировать accessibility, если среди клиентов нет людей с инвалидностью?

Да. Законодательство, стандарты качества и перспективы развития продукта требуют высокой доступности. К тому же часть пользователей может иметь временные ограничения (например, травмы).

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

• Пренебрежение нефункциональными требованиями из-за недооценки их влияния.
• Документирование результатов без ссылок на стандарты.
• Описание багов фразами «некомфортно» или «неудобно» без конкретики.

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

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

Тестировщик не обратил внимания на низкий контраст подписи к кнопке: пользователи с нарушением цветового восприятия не видели текст.

Плюсы:

• Экономия времени на тестировании.

Минусы:

• Пользователи жаловались, увеличилось количество обращений в поддержку, репутационные потери.

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

Тестировщик использовал бесплатную утилиту для проверки контрастности и составил чек-лист accessibility.

Плюсы:

• Раннее выявление дефектов доступности до релиза.
• Увеличение лояльности пользователей.

Минусы:

• Удлинение цикла тестирования.
• Необходимость изучать дополнительные стандарты и инструменты.