ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПО
ТЕСТИРОВАНИЕ ТРЕБОВАНИЙ
ЗАЧЕМ ТЕСТИРОВАТЬ ТРЕБОВАНИЯ?
ЗАЧЕМ ТЕСТИРОВАТЬ ТРЕБОВАНИЯ?
ЗАЧЕМ ТЕСТИРОВАТЬ ТРЕБОВАНИЯ?
Именно в требованиях закрадывается больше всего багов,
а не в коде, как думают многие:
ПРОБЛЕМЫ АНАЛИЗА ТРЕБОВАНИЙ
Проблемы заинтересованных лиц
• Заказчики не понимают то, что они хотят, или у пользователей нет
ясного представления об их требованиях
• Заказчики не соглашаются с ранее записанными требованиями
• Заказчики настаивают на новых требованиях после того, как
стоимость и график работ были установлены
• Коммуникация с заказчиками является медленной
• Заказчики часто не участвуют в обзорах требований или
неспособны в них участвовать
• Заказчики технически неподготовлены
• Заказчики не понимают процесса разработки ПО
ПРОБЛЕМЫ АНАЛИЗА ТРЕБОВАНИЙ
Проблемы инженеров / разработчиков
• У технического персонала и конечных пользователей могут быть
различные мнения.
• Инженеры и разработчики могут попытаться подкорректировать
требования, чтобы они соответствовали существующей системе
или модели, вместо того, чтобы разработать систему,
соответствующую потребностям клиента.
• Анализ может часто выполняться инженерами или
программистами, а не персоналом с навыками работы с
людьми и знаниями проблемной области.
Проблема самих требований (их просто нет)
СТАНДАРТНАЯ СИТУАЦИЯ ИЗ ЖИЗНИ:
ТИПЫ ТРЕБОВАНИЙ
oФункциональные
что система должна делать?
oНефункциональные
при каких условиях система должна
работать?
ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
• Бизнес-требования (business requirements) – определяют
высокоуровневые цели организации или клиента
(потребителя) – заказчика разрабатываемого программного
обеспечения.
• Пользовательские требования (user requirements) –
описывают цели/задачи пользователей системы, которые
должны достигаться/выполняться пользователями при помощи
создаваемой программной системы.
• Функциональные требования (functional requirements) –
определяют функциональность (поведение) программной
системы, которая должна быть создана разработчиками для
предоставления возможности выполнения пользователями
своих обязанностей в рамках бизнес-требований и в
контексте пользовательских требований.
НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия)
Системные требования и ограничения — определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять. К системным требованиям и ограничениям относятся:
• Ограничения на программные интерфейсы, в том числе к внешним системам
• Требования к атрибутам качества• Требования к применяемому оборудованию и ПО Требования к документированию Требования к дизайну и юзабилити Требования к безопасности и надёжности Требования к показателям назначения (производительность,
устойчивость к сбоям и др.) Требования к эксплуатации и персоналу Прочие требования и ограничения (внешние воздействия,
мобильность, автономность и т.п.)
ТЕСТИРОВАНИЕ ДОКУМЕНТАЦИИ ОХВАТЫВАЕТ СЛЕДУЮЩИЕ ВИДЫ ДОКУМЕНТОВ:
• Функциональные спецификации;
• Спецификации по графическому
интерфейсу пользователя;
• Руководства пользователя и онлайновые
справочные системы.
ИСТОЧНИКИ ТРЕБОВАНИЙ
• Законодательство (конституция, законы,
распоряжения)
• Нормативное обеспечение организации
(регламенты, положения, уставы, приказы)
• Текущая организация деятельности объекта
• Модели деятельности (диаграммы бизнес-
процессов)
• Представления и ожидания потребителей и
пользователей системы
• Конкурирующие программные продукты
ТРЕБОВАНИЯ К ТРЕБОВАНИЯМ
Единичность Требование описывает одну и только одну вещь.
Завершённость
(полнота)Требование полностью определено в одном месте и вся необходимая информация присутствует.
Избыточность Отсутствуют избыточные данные.
ПоследовательностьТребование не противоречит другим требованиям и полностью соответствует внешней документации.
АтомарностьТребование «атомарно». То есть оно не может быть разбито на ряд более детальных требований без потери завершённости.
Актуальность Требование не стало устаревшим с течением времени.
Выполнимость Требование может быть реализовано в пределах проекта.
НедвусмысленностьТребование кратко и определено выражает факты. Возможна одна и только одна интерпретация. Определение не содержит нечётких фраз.
ОбязательностьТребование представляет определённую характеристику, которая не может быть проигнорирована и отсутствие которой приведёт к неполноценности решения.
ПроверяемостьРеализованность требования может быть определена через один из методов: осмотр, демонстрация, тест или анализ.
Логичность Логическая взаимосвязь компонентов
КАК ТЕСТИРОВАТЬ ТРЕБОВАНИЯ?
иметь хорошие доменные знания в области
форматировать требования в виде таблиц со
всеми возможными вариантами
обращать внимание на общие формулировки
представить себя на месте
заказчика/аналитика/простого пользователя и
пытаться предположить, будет ли понятно то или
иное требование
руководствоваться здравым смыслом и собственным опытом
КТО ТЕСТИРУЕТ ТРЕБОВАНИЯ?
• Тестировщик (QC, QA)
• Аналитик
• Разработчик (Архитектор, Тех лидер)
• ПМ
• Эксперт в области
• И, вы не поверите, Пользователи и Заказчик
• Иногда все они даже собираются группами!
ЧТО НА ВЫХОДЕ? (РЕЗУЛЬТАТ)
• Требования с указанием недочетов и
рекомендаций по исправлению (логично, да?)
• Список дефектов в баг-трекинг системе (если
по процессу)
• Минимизация будущих расходов на
переработку
• Happy Customers! (а также менеджеры,
аналитики, разработчики и, конечно,
тестировщики)