Тестирование требованийЗачем и Как?

Кто я?
Тестировщик
Тест-менеджер
Руководитель отдела тестирования
____________________
Опыт 4 года
Инструктор
Активный участник конференций

Что будем делать?
Выпустим продукт по не оттестированным требованиям
Посмеемся
Будем тестировать требования, как умеем
Будем тестировать требования по системе
Проанализируем результаты

Структура тренинга
Иллюстрация
Практика 1
Теория - сжато
Практика 2
Анализ результатов

Часть 1. Иллюстрация

Вводные:
Компания «Вакуумная сфера»
разработка ПО
50 человек, из них 35 – разработка
Завязка:
Желание владельца повысить производительность – поиск корня

Компания «Кофе для всех»

Бизнес-требования
Повысить производительность разработчиков
Для этого:
снизить посещаемость кофейни программистами в рабочее время
Попутно:
- избавиться от кавардака на кухне и на рабочих местах

3 варианта решения
- купить франшизу у кофейни, поставить бар
- купить кофемашину
- поставить кофемат (платный либо бесплатный за счет компании)

Выбранный вариант
-купить франшизу у кофейни, поставить бар с баристом
- купить кофемашину
- поставить кофемат (платный либо бесплатный за счет компании)

Процесс выявления требований
Первоначальные требования
Подсчет стоимости
Урезание требований

Свершилось!

Проходит месяц

Нельзя выпить то, что хочется
С утра постоянно не работает
2 раза обжегся
Постоянно нет ложек
Невкусно
Не умею пользоваться
Не заметил
Током бьет
Слишком горячий
Неудобно
Вечно нет сдачи
Не принимает сторублевки
Кидает с купюрами
На рабочем месте нет мусорки

Причины сложившейся ситуации
- Плохое выявление (невыявленные требования)
- Плохое тестирование (выявленные требования)

Причины сложившейся ситуации
- Плохое выявление (невыявленные требования)
- Плохое тестирование (выявленные требования)

Часть 1 1/2. Статистика

Онлайн-статистика

Часть 2. Практика 1

Часть 3. Теория

Что такое требования?
Условие или возможность, требуемая пользователем для решения задач или достижения целей.
Условие или возможность, которые должны удовлетворяться системой/компонентом системы или которыми система/компонент системы должна обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующими документами.
Документальная репрезентация (зафиксированное определение, описание) условий или возможностей, перечисленных в предыдущих пунктах
IEEE Standard Glossary of Software Engineering Terminology

Форма представления
Спецификация требований
Сценарии использования
Стикеры на доске
Мысли менеджера

Какие бывают требования?
Бизнес-требования
Требования пользователей
Функциональные требования
Нефункциональные требования
Предположения и ограничения
Требования связанные с внедрением

Тестирование требований
Когда?
Зачем?
Доколе?

Тестирование требований
Когда?
----- как только появилось хотя бы одно требование
Зачем?
----- уменьшение количества доработок и изменений
----- сокращение рисков
----- ознакомление и согласование задач между разработчиками
Доколе?
----- достаточно информации для начала разработки

Свойства хороших требований
Корректность
Недвусмысленность (однозначность)
Полнота
Непротиворечивость (совместимость)
Упорядоченность (ранжированность )
Проверяемость (тестируемость)
Модифицируемость
Трассируемость (прослеживаемость)
IEEE 830-1998 Recommended Practice for Software Requirements Specifications

Свойства хорошего требования
- Корректность
- Однозначность
- Полнота
- Осуществимость (реализуемость)
- Необходимость
- Назначение приоритета
- Проверяемость
Материалы UML2.RU

Свойства хороших требований
Полнота
Правдивость
Однозначность
Измеримость
Ранжируемость
Не определяющее техническое решение
Осуществимость (реализуемость)
Проверяемость (тестируемость)
Прослеживаемость
Непротиворечивость
Избыточность
Полнота набора

Кубической формы
Ребро 75 мм
Крепкий (ГОСТ №)
Легкий (ГОСТ №)
Травмобезопасный (ГОСТ №)
Безвредный материал (ГОСТ №)
Цветной
Кубической формы
Ребро 75 мм
Пластмассовый (полиэтилен)
Полый
Возможность покрасить

Требование 1: см. базовые требования «Кубик»
Требование 2: зелёный, красный, жёлтый, голубой

Методы тестирования
- Проверка требований (документации)
Анализ поведения системы
Прототипирование

Методы тестирования
- Проверка требований (документации)
Анализ поведения системы
Прототипирование

Кто должен тестировать?
Для эффективного тестирования важно вовлекать различных специалистов
За качество ответственна (в своей области) вся команда
Тестировщики
Аналитики
Менеджер
Разработчики
…

Кто тестирует?
Для эффективного тестирования важно вовлекать различных специалистов
За качество ответственна вся команда
Тестировщики
Аналитики
Менеджер
Разработчики
…

Часть 4. Практика 2

Вариант представления требований: перечисление
Список в виде «Система должна делать…»

Перегруппировка
Бизнес-требования (БТ)
Функциональные требования (ФТ)
Нефункциональные требования (НТ)

Тест № 1
Содержат ли требования выражения типа «подлежит определению», «и так далее», «и прочее» …
Ссылаются ли требования на несуществующие источники?
Ссылается ли на ещё не определенные источники?

Тест № 1
Содержат ли требования выражения типа «подлежит определению», «и так далее», «и прочее» …
Ссылаются ли требования на несуществующие источники?
Ссылается ли на ещё не определенные источники?
Проверяем требования на полноту

Тест № 2
Определяем меру качества для каждого требования:
Верно ли, что каждое требование имеет критерий качества, который можно использовать для проверки того, удовлетворяет ли какое-либо решение требованию?

Тест № 2
Определяем меру качества для каждого требования:
Верно ли, что каждое требование имеет критерий качества, который можно использовать для проверки того, удовлетворяет ли какое-либо решение требованию?
Позволяет выявить неполные, неизмеримые требования

Тест № 3
- Рассматриваем каждое требование как отдельно распознаваемую, измеряемую сущность
Каждое ли требование однозначно распознаваемо?

Тест № 3
- Рассматриваем каждое требование как отдельно распознаваемую, измеряемую сущность
Каждое ли требование однозначно распознаваемо?
Помогает отслеживать требования

Тест № 4
Отслеживаем термины:
Всякая ли ссылка на термин, определенный в спецификации требований, согласуется с этим определением?

Тест № 4
Отслеживаем термины:
Всякая ли ссылка на термин, определенный в спецификации требований, согласуется с этим определением?
Позволяет отследить неоднозначные требования

Тест № 5
Сопоставляем требования и сформулированные цели разработки системы:
Каждое ли требование в спецификации существенно для системы?

Тест № 5
Сопоставляем требования и сформулированные цели разработки системы:
Каждое ли требование в спецификации существенно для системы?
Позволяет выявить несущественные требования

Тест № 6
- Для каждого требования выясняем, почему оно является требованием.
Содержит ли спецификация решения, представленные в виде требований?

Тест № 6
- Для каждого требования выясняем, почему оно является требованием.
Содержит ли спецификация решения, представленные в виде требований?
Позволяет понять, реально ли это ограничения, существующие в контексте проблемы

Тест № 7
Знаем ли мы значение, которое придает требованию заказчик?
Определено ли для каждого требования значение, придаваемое заинтересованными сторонами?

Тест № 7
Знаем ли мы значение, которое придает требованию заказчик?
Определено ли для каждого требования значение, придаваемое заинтересованными сторонами?
Позволяет расставить приоритеты проектирования системы

Тест № 8
Все ли требования из уже известных зафиксированы:
Спрашивали ли мы заинтересованные стороны об осознанных, неосознаваемых и невообразимых требованиях

Тест № 8
Все ли требования из уже известных зафиксированы:
Спрашивали ли мы заинтересованные стороны об осознанных, неосознаваемых и невообразимых требованиях
Позволяет как-то проверить полноту всего объема требований =)

Тест № 9
- Делим требования на управляемые группы
Можем ли мы при каждом изменении в требованиях определить все части системы, на которые оказывает влияние это изменение?

Тест № 9
- Делим требования на управляемые группы
Можем ли мы при каждом изменении в требованиях определить все части системы, на которые оказывает влияние это изменение?
Позволяет отследить взаимосвязи между требованиями, их однозначность и непротиворечивость

Тест № 10
Входим в домен:
Достаточно ли широк контекст требований для охвата всего того, что мы хотим помнить?

Тест № 10
Входим в домен:
Достаточно ли широк контекст требований для охвата всего того, что мы хотим помнить?
Позволяет проверить, рассмотрели ли мы все возможные требования в данном контексте, определить избыточные

Сводная таблица

Вариант представления требований: варианты использования
Юскейсы вида «Действующее лицо делает … для …»

Формальная проверка ВИ

Вариант представления требований: неважно
Во время проектирования тестов

Проектируем тесты «Не хватает денег»

Проектируем тесты «Не хватает денег»

Какой способ выбрать?
Зависит от:
Способа представления требований
Степени формализации в проекте
Количества требований

Ограничения:
Наличие формализованных требований
Наличие роли аналитика в проекте
Выделяется время на старте проекта
Найденные дефекты требований будут исправляться

Итоги:
Как только мы сформулируем хотя бы одно требование, мы можем приступать к его тестированию
Тестирование начинается в самом начале проекта
Способ и уровень формализации выбираете сами

Что могло бы быть?