Тестирование требований Зачем и Как? Юлия Нечаева, Innova Systems

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

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

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

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

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

7

8

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

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

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

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

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

Свершилось! 14

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

16

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

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

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

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

Онлайн-статистика Всего присутствующих: 2020 Из них:В проекте есть требования:1890% Требования формализованы:1477,77778% Требования тестируются:535,71429% 21

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контакты. Я пишу: Я общаюсь: Skype: julia.nechaevajulia.nechaeva 71