Читаем QA Engineer полностью

QA Engineer

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

Пример проранжированности требования

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

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

4.6. Верификация и валидация

Верификация — это проверка того, что программное обеспечение соответствует требованиям и спецификациям.

Пример

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

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

Пример

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

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

4.7. Техники тестирования требований

4.7.1. Анализ требований

Анализ требований — это проверка требования, в ходе которого его изучают и проводят последующий анализ и оценку качества.

Пример

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

4.7.2. Прототипирование

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

Пример

Создан прототип веб — интерфейса корзины покупок. Хоть это только первоначальный набросок того, что реализуют в будущем, уже можно понять, удобен ли функционал для пользователя и правильно ли определён механизм выполнения покупок. Имея прототипы, можно понять, какие требования были ошибочны или недостаточно проработаны. Это позволит в дальнейшем эффективнее пройти валидацию.

4.7.3. Проверка на соответствие

Проверка на соответствие — это техника, в ходе которой проводят проверку требований на предмет соответствия нормативным актам, стандартам и внутренним документам компании.

Пример

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

4.7.4. Анализ проблем

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

Пример

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

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