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

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

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

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

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

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

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

7 7

8 8

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

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

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

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

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

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

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

16 16

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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