Тестирование требований

1. ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПО

2. ТЕСТИРОВАНИЕ
ТРЕБОВАНИЙ

4. ЗАЧЕМ ТЕСТИРОВАТЬ ТРЕБОВАНИЯ?

5. ЗАЧЕМ ТЕСТИРОВАТЬ ТРЕБОВАНИЯ?

6. ЗАЧЕМ ТЕСТИРОВАТЬ ТРЕБОВАНИЯ?
Именно в требованиях закрадывается больше всего багов,
а не в коде, как думают многие:

7. ПРОБЛЕМЫ АНАЛИЗА ТРЕБОВАНИЙ
 Проблемы заинтересованных лиц
• Заказчики не понимают то, что они хотят, или у пользователей нет
ясного представления об их требованиях
• Заказчики не соглашаются с ранее записанными требованиями
• Заказчики настаивают на новых требованиях после того, как
стоимость и график работ были установлены
• Коммуникация с заказчиками является медленной
• Заказчики часто не участвуют в обзорах требований или
неспособны в них участвовать
• Заказчики технически неподготовлены
• Заказчики не понимают процесса разработки ПО

8. ПРОБЛЕМЫ АНАЛИЗА ТРЕБОВАНИЙ
 Проблемы инженеров / разработчиков
• У технического персонала и конечных пользователей могут быть
различные мнения.
• Инженеры и разработчики могут попытаться подкорректировать
требования, чтобы они соответствовали существующей системе
или модели, вместо того, чтобы разработать систему,
соответствующую потребностям клиента.
• Анализ может часто выполняться инженерами или
программистами, а не персоналом с навыками работы с
людьми и знаниями проблемной области.
 Проблема самих требований (их просто нет)

11. СТАНДАРТНАЯ СИТУАЦИЯ ИЗ ЖИЗНИ:

13. ТИПЫ ТРЕБОВАНИЙ
oФункциональные
что система должна делать?
oНефункциональные
при каких условиях система должна
работать?

14. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
• Бизнес-требования (business requirements) – определяют
высокоуровневые цели организации или клиента
(потребителя) – заказчика разрабатываемого программного
обеспечения.
• Пользовательские требования (user requirements) –
описывают цели/задачи пользователей системы, которые
должны достигаться/выполняться пользователями при помощи
создаваемой программной системы.
• Функциональные требования (functional requirements) –
определяют функциональность (поведение) программной
системы, которая должна быть создана разработчиками для
предоставления возможности выполнения пользователями
своих обязанностей в рамках бизнес-требований и в
контексте пользовательских требований.

15. НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
 Бизнес-правила — определяют ограничения, проистекающие из
предметной области и свойств автоматизируемого объекта
(предприятия)
 Системные требования и ограничения — определения
элементарных операций, которые должна иметь система, а также
различных условий, которым она может удовлетворять. К системным
требованиям и ограничениям относятся:
• Ограничения на программные интерфейсы, в том числе к
внешним системам
• Требования к атрибутам качества
• Требования к применяемому оборудованию и ПО
 Требования к документированию
 Требования к дизайну и юзабилити
 Требования к безопасности и надёжности
 Требования к показателям назначения (производительность,
устойчивость к сбоям и др.)
 Требования к эксплуатации и персоналу
 Прочие требования и ограничения (внешние воздействия,
мобильность, автономность и т.п.)

16. ТЕСТИРОВАНИЕ ДОКУМЕНТАЦИИ ОХВАТЫВАЕТ
СЛЕДУЮЩИЕ ВИДЫ ДОКУМЕНТОВ:
• Функциональные спецификации;
• Спецификации по графическому
интерфейсу пользователя;
• Руководства пользователя и онлайновые
справочные системы.

17. ИСТОЧНИКИ ТРЕБОВАНИЙ
• Законодательство (конституция, законы,
распоряжения)
• Нормативное обеспечение организации
(регламенты, положения, уставы, приказы)
• Текущая организация деятельности объекта
• Модели деятельности (диаграммы бизнес-
процессов)
• Представления и ожидания потребителей и
пользователей системы
• Конкурирующие программные продукты

18. ТРЕБОВАНИЯ К ТРЕБОВАНИЯМ 
Единичность Требование описывает одну и только одну вещь.
Завершённость
(полнота)
Требование полностью определено в одном месте и вся
необходимая информация присутствует.
Избыточность Отсутствуют избыточные данные.
Последовательность
Требование не противоречит другим требованиям и полностью
соответствует внешней документации.
Атомарность
Требование «атомарно». То есть оно не может быть разбито на
ряд более детальных требований без потери завершённости.
Актуальность Требование не стало устаревшим с течением времени.
Выполнимость Требование может быть реализовано в пределах проекта.
Недвусмысленность
Требование кратко и определено выражает факты. Возможна
одна и только одна интерпретация. Определение не содержит
нечётких фраз.
Обязательность
Требование представляет определённую характеристику, которая
не может быть проигнорирована и отсутствие которой приведёт к
неполноценности решения.
Проверяемость
Реализованность требования может быть определена через один
из методов: осмотр, демонстрация, тест или анализ.
Логичность Логическая взаимосвязь компонентов

19. КАК ТЕСТИРОВАТЬ ТРЕБОВАНИЯ?
иметь хорошие доменные знания в области
форматировать требования в виде таблиц со
всеми возможными вариантами
обращать внимание на общие формулировки
представить себя на месте
заказчика/аналитика/простого пользователя и
пытаться предположить, будет ли понятно то или
иное требование
руководствоваться здравым смыслом и
собственным опытом 

20. КТО ТЕСТИРУЕТ ТРЕБОВАНИЯ?
• Тестировщик (QC, QA)
• Аналитик
• Разработчик (Архитектор, Тех лидер)
• ПМ
• Эксперт в области
• И, вы не поверите, Пользователи и Заказчик
• Иногда все они даже собираются группами!

21. ЧТО НА ВЫХОДЕ? (РЕЗУЛЬТАТ)
• Требования с указанием недочетов и
рекомендаций по исправлению (логично, да?)
• Список дефектов в баг-трекинг системе (если
по процессу)
• Минимизация будущих расходов на
переработку
• Happy Customers! (а также менеджеры,
аналитики, разработчики и, конечно,
тестировщики)