Пользовательские требования в жизни тестировщика

Тестирование требований
или пользовательские требования в жизни тестировщика

Пользовательские требования в жизни тестировщика
Таисия Толстунова
2
Кто я?
В тестировании/ТМ – 10/7 лет
Люблю требования :)
в явном виде работаю:
с требованиями > 5 лет,
с пользовательскими требованиями 1,5 года

3
Признаки и предпосылки

4
Признаки
• График сходимости дефектов не сходится

5
Признаки
• Ранее разработанный функционал меняется от релиза к релизу

6
Признаки
• Сроки релизов срываются, постоянно

7
Признаки
• Пользователи отказываются от продукта

8
Признаки
• Требования «в данный момент» и «глобально нужно» не совпадают

9
Признаки
• Требования «в данный момент» и «глобально нужно» не совпадают
• При этом… возникает мысль «А если бы мы всё обсудили заранее,
не нужно было бы переделывать и сроки бы не сорвали»

10
Пример
• Сколько родителей у одного ребенка?

11
Пример
• Скольким нужен доступ к электронному дневнику?

12
Пример
• А если родители в разводе и повторно женаты/замужем?

13
Пример
• А если опекунами ребенка являются не родители?

14
Пример
• Сколько раз по вашему менялась цифра в ПО?

15
Пример
• Сколько раз по вашему менялась цифра в ПО?
И представьте, что в какой-то момент в результате данного кейса в ПО
были задублированы и сами дети =)

16
Требования
Что это? Что может сопутствовать?

17
Требования - определение
Пользовательское требование – задача, которую определенные классы
пользователей должны иметь возможность выполнять в системе, или
требуемый атрибут продукта (К. Вигерс)

18
Документирование требований

19
Документирование требований
• Стикерами на ватмане
• Маркером на доске
• Просто текстом
• Use case (вариант использования)
• User story (пользовательская история)
• Любой другой вариант (стандарты предприятия)

20
Артефакты вместе с требованиями
• CRUDL матрицы объектов
• RACI матрицы объектов
• Прототипы интерфейсов
• Списки требований
• Словарь терминов
• Списки заинтересованных лиц и их интересов

21
Примеры
и немного о свойствах требований

22
Свойство ясность – вопросы аббревиатур и терминологии

23
CRUDL (действий):
C – create
R – read
U – update
D – delete
L – list
RACI (ответственности):
R – responsible
A – accountable
C – consumed
I – informed

24
Роль vs Должность

25
Свойство ясность – определение
Требование должно быть недвусмысленным, определенным,
однозначным с определенными терминами. Используемая лексика
должна быть понятна.
В том числе и в рамках использования одних и тех же терминов в
наборе требований.

26
Свойство трассируемость
Требование к системе: сквозная авторизация в системе
Для программных комплексов необходимо данное требование учесть,
несмотря на то, что это функциональное требование.

27
Свойство трассируемость – определение
Возможность отследить связь между разными уровнями требований:
• вверх
• к требованиям системы
• к ТЗ
• вниз
• к функциональным требованиям (постановкам)
• к ПО

28
Свойство полнота
В системе есть объект
справочника, который можно
просматривать и изменять.

29
Свойство полнота
В системе есть объект
справочника, который можно
просматривать и изменять.
Вопросы:
• Кто?
• Что именно делает?
• Есть ли какие-то условия?
• Есть ли какие-то ограничения?
• CRUDL?

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

31
Еще примеры

32
Нормативная информация и аббревиатуры
4.3.4. Техническая поддержка и обновление сайта ВУЗ
4.3.4.1. В ОИ поступает заявка на создание нового ЭУК. В заявке
указывается название курса, фамилия куратора и сроки обучения.
4.3.4.2. Специалист по УМР ОИ принимает и подписывает поступившие
заявки.

33
Нормативная информация и аббревиатуры
4.3.4. Техническая поддержка и обновление сайта ВУЗ
4.3.4.1. В ОИ поступает заявка на создание нового ЭУК. В заявке
указывается название курса, фамилия куратора и сроки обучения.
4.3.4.2. Специалист по УМР ОИ принимает и подписывает поступившие
заявки.
Какими документами необходимо руководствоваться специалисту?
Каким нормам, законам и ГОСТ-ам должна соответствовать система?

34
Тестируемость и полнота
Система управления контентом сайта должна обеспечить
администратору сайта возможность авторизации и разграничения прав
для неограниченного количества операторов сайта.

35
Тестируемость и полнота
Система управления контентом сайта должна обеспечить
администратору сайта возможность авторизации и разграничения прав
для неограниченного количества операторов сайта.
• Существует ли роль «Пользователь»?
• Может ли администратор редактировать свой аккаунт?
• Могут создаваться дополнительные разграничения прав?
• Как можно назначить администратора?

36
Требования не к ПО

37

38
На которой вы стороне сейчас?
• Что происходит с монстрами?
• А даётся ли манчкинам уровень?
• Что происходит, если карту играет
отбивающийся манчкин?

39
Зачем тестировать требования?
и кому это нужно

40
Кому нужно тестирование требований?
• Клиенту
• Конечным пользователям
• Команде и продукту в целом
• Проекту

41
Почему важно клиенту и пользователям?
• Проще согласовывать требования (и уменьшается количество
итераций)
• У клиента есть понимание, что именно будет реализовано и для чего
• Заранее известно, что реализовать невозможно
• Не нужно привыкать к новым реализациям привычного функционала
• Кейсы для пользователей учитываются при разработке и становятся
возможны к использованию

42
Почему важно команде и продукту в целом?
• Общее понимание требований у всей команды
• Видны противоречия с ранними требованиями в пожеланиях
• Не планируется реализовать невозможное
• Не забываются «мелочи»
• …
• Экономятся средства за счет исправления ошибок не в стадии
готового продукта

43
Почему важно проекту?
• Функционал реализуется 1 раз, отсутствует постоянная переработка
• Можно более точно планировать сроки и объем выполнения работ

44
Формализация процесса

45
Формализация – что нужно сделать сначала?
• Определить, в каком виде есть требования в вашей команде
• Попробовать тестировать требования, подобрать комфортный для
команды вариант
• Формализовать процесс на бумаге или в голове

46
Формализация – что важно помнить?
• Когда и зачем нужна формализация?
• Кто должен тестировать требования?
• Важен ли порядок тестирования?
• Что брать в основу процесса?
• Формализовать можно не всё

47
Формализация – что важно помнить?

48
Success-story

49
Пример
Заявления подаются в «черную дыру»

50
Пример

51
Пример
1. Сформировали вопросы
2. Через выполняющего роль аналитика задали вопросы заказчику
3. Согласовали итоговый вариант после нескольких итераций
4. Стали реализовывать логику внутри ПО
К моменту ввода системы в эксплуатацию – ошибки не было

52
Материалы по тестированию требований

53
Материалы
1. К.Вигерс и Дж.Битти. Разработка требований к ПО
2. Анна Абрамова. Что такое Use Case и зачем они нужны?
3. Алексей Федоров. Шагнуть на встречу тестированию требований
4. Сергей Мартыненко. Написание тестов, как вид тестирования
требований
5. Niels Malotaux. Inspection used in various ways

54
Материалы
1. Юлия Нечаева. Тестирование требований: КАК?
2. Андрей Курьян. Метод VCM+ для выявления противоречий в
требованиях заинтересованных лиц
3. Сергей Мартыненко. Приоритизация методов верификации
требований
4. Еще несколько презентаций: 1, 2, 3

Вопросы?
Skype: thaya.tt
email: i@thaya.pro

Пользовательские требования в жизни тестировщика

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Пользовательские требования в жизни тестировщика

Similar to Пользовательские требования в жизни тестировщика (20)

More from SQALab

More from SQALab (20)

Пользовательские требования в жизни тестировщика