Verification – постоянно выполняемый аналитический процесс проверки того, что разработка находится на правильном пути: каждый этап разработки является корректным, необходимым (не лишним) и удовлетворяет потребности следующего этапа. Проводится на всех этапах разработки. На каждом этапе следует убеждаться, что сделали именно то, что планировали, и это соответствует общей логике разработке. «Мы создаем систему правильно».
Validation (проверка правильности) — процесс проверки того, что реализованная система удовлетворяет предъявленным требованиям и работает так, как предполагалось. «Мы создаем правильную систему».
А теперь давайте рассмотрим эти 2 процесса подробнее.
Верификация
Согласно стандарту IEEE 1994, верификация — это
процесс оценки системы/компонента с целью определить, удовлетворяют ли результаты конкретной фазы условиям, наложенным в начале этой фазы.
Верификация позволяет убедиться в корректности переходов между фазами:
- Потребности пользователей (stakeholder requests)
- Функции продукта (функции, features)
- Требования (requirements)
- Архитектура
- Модель проектирования (design model)
- Реализация
- Планирование тестов
Верифицировать следует:
- Описанные функции системы действительно соответствуют потребностям клиента/пользователей.
- Варианты использования и требования, созданные на основе функций, поддерживают эти функции.
- Варианты использования реализуются при проектировании.
- Проектирование поддерживает функциональное и нефункциональное поведение системы.
- Программный код соответствует целям и результатам проектирования.
- Тесты полностью покрывают варианты использования и требования.
Верификация — больше чем деятельность группы по обеспечению качества (QA).
Нужно исследовать требования и ВИ и убедиться, что они полно и неизбыточно отвечают потребностям пользователей (функциям) верхнего уровня (п.2). Далее убедиться, что при проектировании использовались эти требования и ВИ, а технический проект получился полным и неизбыточным.
Валидация
Согласно стандарту IEEE 1994, валидация (проверка правильности) — это
процесс оценки системы/компонента во время или по окончании процесса разработки с целью определить, удовлетворяет ли она заданным требованиям.
Для проверки правильности проводятся приёмо-сдаточные испытания. Они основаны на сценариях тестирования, которые пользователь согласовывает, а затем выполняет в среде использования системы. Стандарт IEEE 829-2008 (Standard for Software and System Test Documentation) содержит образцы 8 документов, которыми следуют руководствоваться при планировании, организации и проведении тестирование:
- План тестирования. Руководящий документ, отражающий:
- Как будет проводиться тестирование, включая конфигурации тестируемой системы (ТС).
- Кто будет тестировать.
- Что будет тестироваться.
- Сколько времени займёт тестирование.
- Какой уровень качества тестирования необходим.
- Критерии успешности тестирования (Test Design Specification).
- Данные для тестирования (Test Case Specification).
- Сценарии тестирования (Test Procedure Specification), включая предусловия и шаги тестов.
- Отчет о переходах между этапами тестирования (Test Item Transmittal Report).
- Протокол тестирования (Test Log).
- Отчет об инцидентах (Test Incident Report), включая ожидаемый результат, фактический результат, время, предполагаемые причины инцидента и всё, что может помочь с разрешением ситуации. Инцидент — не обязательно подразумевает ошибку в системе: ожидаемый результат мог быть неверным, проверка могла проводиться неверно, требование могло толковаться по-другому.
- Отчет от тестировании (Test Summary Report).