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

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

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

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

Пример

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

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

Пример

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

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

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

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

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

Пример

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

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

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

Пример

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

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

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

Пример

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

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

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

Пример

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

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

4.8. Тест — дизайн и техники тестирования

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

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

4.8.1. Техника разделения на классы эквивалентности

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

Пример

Если приложение принимает ввод числа от 1 до 100, то можно определить три класса эквивалентности: числа меньше 1, числа от 1 до 100 и числа больше 100. Достаточно протестировать по одному значению из каждого класса. Таким образом, вместо огромного количество вариантов остается только три, что существенно сократит время тестирования.

4.8.2. Техника граничных значений

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

Пример

Продолжаем пример с приложением, принимающим числа от 1 до 100. У нас имеется две границы целых чисел: 1 и 100. Применяя технику граничных значений, можно сделать вывод, что необходимо проверить значения 0, 1, 100 и 101. То есть, используется одно значение из группы значений выше правильных данных, одно — ниже их и два значения из одной группы, которые являются границами.

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

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

4.8.3. Техника попарного тестирования

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

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

Пример

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

Набор данных будет такой:

— Операционные системы (Windows, macOS, Linux).

— Браузеры (Firefox, Chrome, Safari).

— Языки (Английский, Русский, Испанский).

Вычислить все варианты проверок несложно: