Лекция Тестирование требований

План лекции
Введение.
Виды проектной документации.
Требования к документации.
Уровни требований к ПО.
Принципы тестирования требований.
Характеристики требований.
Как проверять требования по каждой характеристике.
Выводы.

Тестирование требований — это их проверка, чтобы найти ошибки до начала разработки.
Стив Макконнелл в книге «Сколько стоит программный проект» пишет, что при разработке требований в продукт вносят порядка 30% ошибок.
Тестирование требований

01
Для менеджера
Увеличивается скорость разработки
Раньше получает важную информацию
Выше качество продукта
Польза тестирования требований

01
Для менеджера
Увеличивается скорость разработки
Раньше получает важную информацию
Выше качество продукта
Польза тестирования требований
02
Для автора требования
Обратная связь
Дополнительная информация
Меньше вопросов
4

01
Для менеджера
Увеличивается скорость разработки
Раньше получает важную информацию
Выше качество продукта
Польза тестирования требований
02
Для автора требования
Обратная связь
Дополнительная информация
Меньше вопросов
03
Для разработчика
Качественные требования
Меньше новых требований
4

01
Для менеджера
Увеличивается скорость разработки
Раньше получает важную информацию
Выше качество продукта
Польза тестирования требований
02
Для автора требования
Обратная связь
Дополнительная информация
Меньше вопросов
03
Для разработчика
Качественные требования
Меньше новых требований
04
Для тестировщика
Влияние на проект
Меньше багов
Понятнее конечный результат
4

01
Бизнес-требования
Какие и чьи проблемы решает продукт
Уровни требований
6

01
Бизнес-требования
Какие и чьи проблемы решает продукт
Уровни требований
02
6
Пользовательские требования
Кто как и зачем взаимодействует с продуктом

01
Бизнес-требования
Какие и чьи проблемы решает продукт
Уровни требований
02
03
Требования к реализации
Функциональные, компонентные, модульные и требования к подсистемам, и нефункциональные требования
6
Пользовательские требования
Кто как и зачем взаимодействует с продуктом

Пример про кофе-автомат
7

Пример про кофе-автомат
7

Пример про кофе-автомат
7

Пример про кофе-автомат
7

Пример про кофе-автомат
7

Виды документации
8
01
Предпроектная
концепции, технические задания, технические требования и т.д.

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

Виды документации
8
01
Предпроектная
концепции, технические задания, технические требования и т.д.
02
Проектная
пояснительные записки, задачи и т.д.
03
Эксплуатационная
руководство пользователя/администратора, технологические инструкции и т.д.

01
Предпроектная
концепции, технические задания, технические требования и т.д.
Виды документации
02
Проектная
пояснительные записки, задачи и т.д.
03
Эксплуатационная
руководство пользователя/администратора, технологические инструкции и т.д.
04
Прочие документы
документы организационно-распорядительного характера и корпоративные документы
8

Совет: Выбрать ГОСТы, в соответствии с которыми планируется разработка документа, всегда лучше до начала разработки, т.к. ГОСТы определяют не только оформление, но и содержание, а также методику подачи материала.
Требования к документации
ГОСТ 19 (ЕСПД)
ГОСТ 34 (КСАС)
ГОСТ 2 (ЕСКД)

Рекомендации для тестирования требований
5
До старта разработки

Рекомендации для тестирования требований
5
До старта разработки
Проверяет не тот, кто писал

Рекомендации для тестирования требований
Заведение дефектов
5
До старта разработки
Проверяет не тот, кто писал

Рекомендации для тестирования требований
Заведение дефектов
5
До старта разработки
Проверяет не тот, кто писал
Предупреждать команду

Рекомендации для тестирования требований
Заведение дефектов
Детализация требований соответствует проекту
5
До старта разработки
Проверяет не тот, кто писал
Предупреждать команду

Характеристики требований
9

Характеристики требований
Корректность и согласованность
Необходимость
Осуществимость
Проверяемость
Полнота
Однозначность
Непротиворечивость
ISO/IEC/IEEE 29148:2018
В стандарте описаны содержание и качества хорошей спецификации требований к программному обеспечению
IEEE/EIA12207.1-1997
Стандарт предоставляется рекомендации по соответствию требованиям на всём жизненном цикле разработки

Полнота
10
Требование должно содержать всю необходимую информацию для его реализации.

Однозначность
12
Все работающие с требованием должны понимать его одинаково.

Корректность
14
Требование не должно содержать в себе неверной, неточной информации.

Непротиворечивость
16
Требование не должно противоречить самому себе, а отдельные требования в системе требований не должны противоречить друг другу.

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

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

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

Проверка требований
25
Начать тестирование требований можно с поверхностного осмотра документации.
После прочтения документации не должно быть вопросов. Совсем.

Проверка на полноту требований
26
CRUD

Проверка на полноту требований
26
CRUD
Сценарии использования

Проверка на полноту требований
Таблица решений
26
CRUD
Сценарии использования

Проверка на полноту требований
Таблица решений
26
CRUD
Сценарии использования
Учтены ли интересы всех?

Проверка на полноту требований
Таблица решений
Отсылки на неопределённую информацию
26
CRUD
Сценарии использования
Учтены ли интересы всех?

Проверка на однозначность требований
27
Терминология

Проверка на однозначность требований
27
Терминология
Отсутствие качественных определений

Проверка на однозначность требований
Простота изложения
27
Терминология
Отсутствие качественных определений

Проверка на корректность требований
28
Знание предметной области

Проверка на корректность требований
28
Блок-схема
Знание предметной области

Проверка на корректность требований
28
Блок-схема
Описан основной функционал
Знание предметной области

Проверка на корректность требований
Подробно описано взаимодействие модулей
28
Блок-схема
Описан основной функционал
Знание предметной области

Проверка на непротиворечивость требований
29
Одно требование описано в нескольких местах

Проверка на непротиворечивость требований
29
Одно требование описано в нескольких местах
Союз «и»

Проверка на необходимость требований
30
User story

Проверка на осуществимость требований
31
Сторонний сервис обрабатывает все необходимые запросы

Проверка на осуществимость требований
31
Сторонний сервис обрабатывает все необходимые запросы
Аналитик указал всю необходимую для разработки информацию

Проверка на осуществимость требований
31
Сторонний сервис обрабатывает все необходимые запросы
Аналитик указал всю необходимую для разработки информацию
Посмотреть примеры реализации в других проектах

Проверка на проверяемость требований
32
Разработать набор тестов

Проверка на проверяемость требований
32
Разработать набор тестов
Договорённости из чатов перенесены в документацию

Проверка на проверяемость требований
32
Разработать набор тестов
Договорённости из чатов перенесены в документацию
Сравнение дат обновления документации и требований

Техники тестирования требований
Тест-кейсы и чек-листы
Придумывать при просмотре требований
Исследование поведения системы
Мысленное моделирование работы пользователя с системой
Рисунки
Наглядное представление приложения
Прототипирование
Наброски интерфейса и переходов между экранными формами
Взаимный просмотр
Автор показывает свою работу коллегам
Вопросы
Заказчикам и коллегам

Бонус: мнемоника CIRCUS MATTA
Completeness — полнота
Independent — независимость
Realisable — реализуемость
Consistency — консистентность
Unambiguity — однозначность
Specific — специфика заказчика
Measurable — измеримая
Acceptable — приемлемая
Testable — тестируемая
Traceable — трассируемая (можно проставить взаимосвязи)
Achievable — достижимая

Библиотека ГОСТов http://techwrconsult.com/library/index
Статья Натальи Желновой «Нефункциональные требования к программному обеспечению. Часть 1» https://habr.com/ru/post/231961/
Статья «Тестирование документации к программным продуктам» https://habr.com/ru/post/346290/ (включает 18 параметров, в том числе для пользовательской документации)
Для любознательных

На форму редактирования и создания заявления в раздел «Сведения о проекте и цели обращения» в блок полей «Цель обращения» добавить поле ввода: «Сведения о сметной или предполагаемой (предельной) стоимости объекта капитального строительства, содержащиеся в решении по объекту или письме. тыс. руб.». Формат поля: неотрицательные целые и дробные числа.
Данное поле отображать для всех целей обращения. Заполнение данного поля должно быть обязательным для всех целей обращения, указанных в п.1 описания требований.
Пример №1

Замечания к примеру №1
А формы редактирования и создания одинаковые? Возможно, требования для них отличаются и нуждаются в отдельном описании.
Всегда ли должна срабатывать проверка на обязательность заполнения данного поля?
В блок полей – это в какое конкретно место? Если бы не было скрина, то это было бы не очевидно.
Формат поля обозначен, а длина? Какое максимальное и минимальное значения возможны?
Должно ли в поле что-то отображаться до заполнения? На скрине 0.0, а в условиях не сказано ничего.
Какие тексты ошибок и в каком виде выводить, если поле не заполнено или заполнено недопустимыми данными?
Ссылка на п.1 требований – каких требований и где их искать? Когда нашли, проверить, что там действительна указана требуемая информация.
Должно ли это поле как-то отображаться на карточке заявления после его создания, то есть, когда оно уже не редактируется?

Пример №2

Замечания к примеру №2
Скрины ссылками ни в описании задач, ни в баг-репортах давать нельзя! Со временем они могут стать недоступны.
Соисполнители, исполнители… Даже знающий проект человек легко запутается в этом описании. Стоило указывать точные названия интересующих полей.
Зачёркивание обычно использую для того, что не нужно, например, какое-то требование решили не делать. В данном случае зачёркнуто прежнее название полей, что затрудняет чтение. Проще названия взять в кавычки, а не с начертанием текста играть.
Нужно приложить картинку для иконки «корзины», иначе по всей программе могут получиться разные виды корзины и не будет ощущения целостности ПО.