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

1. Театр начинается с вешалкиТеатр начинается с вешалки
илиили
тестирование требованийтестирование требований
Доклад
16 июля 2015 года
Игорь Лужанский

2. Об автореОб авторе
22
 Профессиональная деятельность
 СЕО и совладелец Neadevis
 10 лет в ИТ индустрии
 Образование
 Днепропетровский Национальный Университет
 Executive MBA, Berlin Steinbais University
 В довесок
 Турист
 Художественный руководитель 2х театров

3. 33
СодержаниеСодержание
 Вступление
 Методы тестирования требований
 Проверка документации
 Анализ поведения системы
 Прототипирование
 Критерии оценки качества требований
 Не зависящие от проекта и технологий
 Зависящие от проекта или технологий
 Заключение

4. 66
Требования должны быть достаточнымиТребования должны быть достаточными
для начала разработкидля начала разработки
 Перед тестированием требований
 Требования проанализированы и задокументированы аналитиком
 Аналитик самостоятельно произвел проверку
 Во время тестирования требований
 Заинтересованные лица подтверждают, что требования корректны и поняты
 Пользователи подтверждают, что требования отражают их потребности
 Критерий готовности требований
 В требованиях содержится достаточно информации для начала разработки
 Участники тестирования требований
 Заказчик, пользователи, проектная команда
Пример из жизни: Как происходит пересмотр требований у нас в компании

5. 77
Тестирование требований играет важнуюТестирование требований играет важную
роль в процессе разработки ПОроль в процессе разработки ПО
 Уменьшение количества доработок и изменений
 Сокращение рисков
 Ознакомление и согласование задач между разработчиками
Аналогия: Входной контроль качества

6. Методы тестирования требованийМетоды тестирования требований
 Вступление
 Методы тестирования требований
 Проверка документации
 Анализ поведения системы
 Прототипирование
 Критерии оценки качества требований
 Не зависящие от проекта и технологий
 Зависящие от проекта или технологий
 Заключение

7. 99
Проверка требований самыйПроверка требований самый
распространенный метод тестированияраспространенный метод тестирования
требованийтребований
 Описание метода
 Последовательный пересмотр и проверка всех требований
 Позволяет проверить на
 Правильность, полноту, прослеживаемость , важность, понятность,
однозначность и измеримость
 Применяется
 Заказчиками, аналитиками, проектными менеджерами,
тестировщиками
 Пример использования
 Формальные Check list’ы

8. 1010
Проверка требований самый простой и ненадежныйПроверка требований самый простой и ненадежный
метод тестирования требованийметод тестирования требований
 Сильные стороны
 Простота использования
 Отсутствие специальных требований к проверяющему
 Покрывает много критериев качества
 Меньшие затраты времени
 Слабые стороны
 Качество проверки зависит от проверяющего
 Вовлечение различных специалистов
 Наличия документа с требованиями

9. 1111
Анализ поведения системы требует специальныхАнализ поведения системы требует специальных
навыков и подготовкинавыков и подготовки
 Описание метода
 Формирование требований в формате вход-выход, событие-
последствие, условие-ответ
 При {событие} система/пользователь {выполняет функцию}
 Если {условие} то система {отвечает}
 Применяется чаще всего
 Тестровщиками (test cases)
 Аналитиками (use cases)
 Позволяет проверить на
 полноту, понятность, однозначность

10. 1212
Анализ поведения системы мощныйАнализ поведения системы мощный
инструмент проверки требованийинструмент проверки требований
 Сильные стороны
 Хорошо проверяет требования
 Представляет требования в структурированном и понятном виде
 Результаты метода легко используются для создания сценариев
тестирования
 Слабые стороны
 Требует большего количества времени
 Требует специальной подготовки

11. 1313
Прототипирование эффектно для проверкиПрототипирование эффектно для проверки
требований на полноту и на выполнимостьтребований на полноту и на выполнимость
 Описание метода
 Создание модели будущей системы
 Применяется чаще для проверки
 Полнота, правильность, реализуемость, удобство использования
 Используется
 Аналитиками, архитекторами
 Пример использования
 Горизонтальный – модель как можно более широкого набора
функциональности
 Вертикальный – подробная узконаправленная модель небольшой части
системы
 Throw-away – не используется в дальнейшей разработке
 Эволюционный – постепенно дорабатывается и превращается в готовую
систему
Лучшие практики: Взгляды на прототип различных специалистов

12. 1414
Создание хорошего прототипа требует значительныхСоздание хорошего прототипа требует значительных
затрат временизатрат времени
 Сильные стороны
 Пользователи получают возможность проверить решение
 Наглядное пособие для разработчиков и тестировщиков
 Проверка требования на реализуемость и на удобство
пользовательского интерфейса
 Слабые стороны
 Требует значительного времени
 Специальная подготовка для создания эволюционного прототипа

13. 1515
Инструмент тестирования требований зависит отИнструмент тестирования требований зависит от
сложности проекта и наличия специалистовсложности проекта и наличия специалистов
 Инструменты тестирования требований не являются открытием
для большинства специалистов
 Полнота требований – основной характеристика требований, на
проверку которой направлены все инструменты тестирования
 Для эффективного тестирования важно вовлекать различных
специалистов

14. 1616
Критерии оценки качества требований неКритерии оценки качества требований не
зависящие от проекта и технологийзависящие от проекта и технологий
 Вступление
 Методы тестирования требований
 Проверка документации
 Анализ поведения системы
 Прототипирование
 Критерии оценки качества требований
 Не зависящие от проекта и технологий
 Правильность
 Полнота
 Понятность
 Непротиворечивость
 Не определяющие реализацию
 Измеримость (проверяемость)
 Зависящие от проекта или технологий
 Заключение

15. 1717
Проектной команде сложно проверитьПроектной команде сложно проверить
требование на правильностьтребование на правильность
 Описание критерия
 Каждое требование должно точно описывать то что должно быть разработано
 Не соблюдение критерия приводит
 Разработка не правильной функциональности
 Как тестируется
 Проверка документации или прототипа на правильность
 Кем тестируется
 Человеком выставляющим требования, специалистом в предметной области
 Пример – правильно ли решение уравнения y3+py+q =0 ?
Правильность

16. 1818
Неполнота требований составляет большойНеполнота требований составляет большой
риск для проектариск для проекта
 Описание критерия
 Все требования задокументированы
 Каждое требование содержит всю информацию необходимую для
проектирования, разработки и тестирования
 Не соблюдение критерия приводит
 Расползанию содержимого
 Неудовлетворенности пользователей
 Почему критерий не достигается
 Отсутствие представления о системе
 Недостаточное внимание к контексту системы
 Недостаточный анализ требований
 Отсутствие ответственности
Полнота

17. 1919
Важно применять весь спектор методовВажно применять весь спектор методов
тестирования требований на полнотутестирования требований на полноту
 Как тестируется?
 Получением от пользователей ответов на вопросы
 Какие ещё есть неописанные, неосознанные требования?
 Что не так в текущей системе?
 Созданием модели поведения системы
 Разработкой прототипа системы
 Анализ контекста в котором будет использоваться система
 Кем тестируется?
 Пользователями, тестировщиками
 Пример – система должна решать квадратное уравнение по формуле
Являются ли требование полным?
Полнота
Пример из жизни: Анализ контекста для тестирования системы рекрутинговой системы

18. 2020
Требование , интерпретируемое по разному,Требование , интерпретируемое по разному,
должно быть переработано или удаленнодолжно быть переработано или удаленно
Понятность
 Описание критерия
 Одинаковая интерпретация (отсутствие друхсмыслености) требования
 Требование описано - четко, просто, кратко
 Все специальные термины описаны и определены
 Не соблюдение критерия приводит
 К необходимости переделывать работу
 Как тестируется?
 Проверка спецификации
 На наличие описания каждого из терминов предметной области
 Соответствие каждого из терминов встречающегося в спецификации своему определению
 Кем тестируется?
 Тестировщиками, разработчиками

19. 2121
Важно убедиться что реализация одногоВажно убедиться что реализация одного
требования не помешает реализации другоготребования не помешает реализации другого
Непротиворечивость
 Описание критерия
 Требование может быть реализовано без конфликта с другими требованиями
 Не соблюдение критерия приводит
 К необходимости переделывать работу
 Как тестируется?
 Проверка спецификации
 Создание прототипа
 Кем тестируется?
 Тестировщиками, разработчиками, аналитиками

20. 2222
Не определяющее
тех. решение Описание критерия
 Требование должно быть сформулировано так что бы предоставлять
широкий выбор вариантов его реализации
 Не соблюдение критерия приводит
 Созданию неэффективного решения
 Потери реальных требований
 Критерий не достигается, потому что пользователи
 Считают, что их роль в принятии решений о дизайне системы
 Не заявляют о своих реальных потребностях
 Разработчиками, архитекторами
 Пример – является ли следующее требование некачественным?
 Система должна быть реализована на С++ так как это единственная
технология, которую знают наши программисты
Важно различать навязывание техническогоВажно различать навязывание технического
решения от проектных ограниченийрешения от проектных ограничений
Пример из жизни: Изначальная постановка задачи к системе управления запасами

21. 2323
Требование, которое невозможно измерить должноТребование, которое невозможно измерить должно
быть переработанно или исключеннобыть переработанно или исключенно
Измеримость
 Описание критерия
 Требование должно быть сформулировано так что бы можно было доказать соответствие
системы предъявленному требованию
 Требование не должно содержать неизмеримых или не тестируемых формулировок
 Как тестируется?
 Проверка требований на измеримость и тестируемость слов и формулировок
 Кем тестируется?
 Тестировщиками
 Пример слов, которые встречаются в неизмеримых требованиях
 Легко, лучше чем, более эффективно, качественно, максимально, минимально
Пример из жизни: При загрузке примерно 200 активов система должна откликаться за 2-3 секунды

22. 2424
Критерии качества требований зависящие отКритерии качества требований зависящие от
проекта и технологийпроекта и технологий
 Вступление
 Методы тестирования требований
 Проверка документации
 Анализ поведения системы
 Прототипирование
 Критерии оценки качества требований
 Не зависящие от проекта и технологий
 Зависящие от проекта или технологий
 Достижимость
 Реализуемость
 Необходимость
 Приоритезируемость
 Прослеживаемость
 Заключение

23. 2525
Заказчикам важно знать планируемые трудозатратыЗаказчикам важно знать планируемые трудозатраты
на реализацию каждого требованияна реализацию каждого требования
Достижимость
 Описание критерия
 Требование технически реализуемо и его реализация вписываться во временные и финансовые
ограничения проекта
 Не соблюдение критерия приводит к
 Сорванным срокам
 Перерасходу бюджета
 Как тестируется?
 Согласованием оценок трудозатрат на реализацию требования
 Кем тестируется?
 Проектным менеджером
Пример из жизни: Сбор и согласование требований к будущим системам в HR

24. 2626
Перед подписанием спецификации менеджеруПеред подписанием спецификации менеджеру
важно убедиться в реализуемости требованийважно убедиться в реализуемости требований
Реализуемость
 Описание критерия
 Каждое требование возможно реализовать с учетом технических и организационных ограничений
 Не соблюдение критерия приводит
 Срывам сроков работ
 Невозможности реализовать полное содержимое проекта
 Как тестируется?
 Созданием прототипа
 Исследованиями ограничений, используемых технологий
 Кем тестируется?
 Архитекторами, разработчиками

25. 2727
20% требований решают 80% задач поставленных20% требований решают 80% задач поставленных
перед системойперед системой
Важность
 Описание критерия
 У каждого требования есть приоритет обозначающий значимость требования в релизе
 Должна быть возможность проследить связь каждого из требований к целям и задачам проекта
 Не соблюдение критерия приводит
 Невозможности гибко управлять изменениями в содержании проекта
 Невозможности полностью решить бизнес задачу
 Критерий не достигается, потому что
 Пользователи создают требования «про запас»
 Как тестируется?
 Проверка требований на наличие важности и связь с целью проекта? (достигнем ли цели, если
не реализовывать это требование?)
 Кем тестируется?
 Заказчиком, проектным менеджером
Пример из жизни: Урезание функциональности HR системы

26. 2828
Отсутствие прослеживаемости затрудняет процессОтсутствие прослеживаемости затрудняет процесс
изменения требованийизменения требований
Прослеживаемость
 Описание критерия
 Каждое требование может быть соотнесено к элементу системы, где оно должно быть реализовано
 Каждое системное требование может быть сопоставлено с бизнес требованием ( в обратном порядке
тоже)
 Не соблюдение критерия приводит
 Не возможности эффективно управлять процессом изменения требований ( важные требования могут
быть потеряны или наоборот незначимые реализованы)
 Критерий не достигается
 Из-за сложной структуры требований
 Как тестируется?
 Проверкой системных требований на наличие ссылок на бизнес требования
 Кем тестируется?
 Аналитиками, заказчиками

27. 2929
ЗаключениеЗаключение
 Вступление
 Методы тестирования требований
 Проверка документации
 Анализ поведения системы
 Прототипирование
 Критерии оценки качества требований
 Не зависящие от проекта и технологий
 Зависящие от проекта или технологий
 Заключение

28. 3030
ВыводыВыводы
 Требования важно тестировать для того что бы
гарантировать высокое качество системы
 У требований есть много критериев, которым они должны
удовлетворять
 Тестирование требований выполняется широким кругом
специалистов

29. 3131
?