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

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

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

Кто я?

Таисия Толстунова

В тестировании/ТМ – 10/7 летЛюблю требования :)

в явном виде работаю:

с требованиями > 5 лет,с пользовательскими требованиями 1,5 года


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


Признаки

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


Признаки


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


Признаки



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


Признаки




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


Признаки





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


Признаки





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

• При этом… возникает мысль «А если бы мы всё обсудили заранее,

не нужно было бы переделывать и сроки бы не сорвали»


Пример

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


Пример


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


Пример



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


Пример




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


Пример





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


Пример





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

И представьте, что в какой-то момент в результате данного кейса в ПО

были задублированы и сами дети =)


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


Требования - определение

Пользовательское требование – задача, которую определенные классы

пользователей должны иметь возможность выполнять в системе, или

требуемый атрибут продукта (К. Вигерс)


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


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

• Стикерами на ватмане

• Маркером на доске

• Просто текстом

• Use case (вариант использования)

• User story (пользовательская история)

• Любой другой вариант (стандарты предприятия)


Артефакты вместе с требованиями

• CRUDL матрицы объектов

• RACI матрицы объектов

• Прототипы интерфейсов

• Списки требований

• Словарь терминов

• Списки заинтересованных лиц и их интересов


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


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



CRUDL (действий):C – createR – readU – updateD – deleteL – list

RACI (ответственности):R – responsible A – accountableC – consumedI – informed



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


Свойство ясность – определение

Требование должно быть недвусмысленным, определенным,

однозначным с определенными терминами. Используемая лексика

должна быть понятна.

В том числе и в рамках использования одних и тех же терминов в

наборе требований.


Свойство трассируемость

Требование к системе: сквозная авторизация в системе

Для программных комплексов необходимо данное требование учесть,

несмотря на то, что это функциональное требование.


Свойство трассируемость – определение

Возможность отследить связь между разными уровнями требований:

• вверх

• к требованиям системы

• к ТЗ

• вниз

• к функциональным требованиям (постановкам)

• к ПО


Свойство полнота

В системе есть объект

справочника, который можно

просматривать и изменять.


Свойство полнота

В системе есть объект

справочника, который можно

просматривать и изменять.

Вопросы:

• Кто?

• Что именно делает?

• Есть ли какие-то условия?

• Есть ли какие-то ограничения?

• CRUDL?


Свойство полнота – определение

Полнота отдельного требования – текст требования не требует

дополнительной детализации, то есть в нем предусмотрены все

необходимые нюансы, особенности и детали данного требования

Полнота системы требований – совокупность артефактов,

описывающих требования, исчерпывающим образом описывает все то,

что требуется от разрабатываемой системы


Еще примеры


Нормативная информация и аббревиатуры

4.3.4. Техническая поддержка и обновление сайта ВУЗ

4.3.4.1. В ОИ поступает заявка на создание нового ЭУК. В заявке

указывается название курса, фамилия куратора и сроки обучения.

4.3.4.2. Специалист по УМР ОИ принимает и подписывает поступившие

заявки.


Нормативная информация и аббревиатуры

4.3.4. Техническая поддержка и обновление сайта ВУЗ

4.3.4.1. В ОИ поступает заявка на создание нового ЭУК. В заявке

указывается название курса, фамилия куратора и сроки обучения.

4.3.4.2. Специалист по УМР ОИ принимает и подписывает поступившие

заявки.

Какими документами необходимо руководствоваться специалисту?

Каким нормам, законам и ГОСТ-ам должна соответствовать система?


Тестируемость и полнота

Система управления контентом сайта должна обеспечить

администратору сайта возможность авторизации и разграничения прав

для неограниченного количества операторов сайта.


Тестируемость и полнота

Система управления контентом сайта должна обеспечить

администратору сайта возможность авторизации и разграничения прав

для неограниченного количества операторов сайта.

• Существует ли роль «Пользователь»?

• Может ли администратор редактировать свой аккаунт?

• Могут создаваться дополнительные разграничения прав?

• Как можно назначить администратора?


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





На которой вы стороне сейчас?

• Что происходит с монстрами?

• А даётся ли манчкинам уровень?

• Что происходит, если карту играет

отбивающийся манчкин?


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


Кому нужно тестирование требований?

• Клиенту

• Конечным пользователям

• Команде и продукту в целом

• Проекту


Почему важно клиенту и пользователям?

• Проще согласовывать требования (и уменьшается количество

итераций)

• У клиента есть понимание, что именно будет реализовано и для чего

• Заранее известно, что реализовать невозможно

• Не нужно привыкать к новым реализациям привычного функционала

• Кейсы для пользователей учитываются при разработке и становятся

возможны к использованию


Почему важно команде и продукту в целом?

• Общее понимание требований у всей команды

• Видны противоречия с ранними требованиями в пожеланиях

• Не планируется реализовать невозможное

• Не забываются «мелочи»

• …

• Экономятся средства за счет исправления ошибок не в стадии

готового продукта


Почему важно проекту?

• Функционал реализуется 1 раз, отсутствует постоянная переработка

• Можно более точно планировать сроки и объем выполнения работ


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


Формализация – что нужно сделать сначала?

• Определить, в каком виде есть требования в вашей команде

• Попробовать тестировать требования, подобрать комфортный для

команды вариант

• Формализовать процесс на бумаге или в голове


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

• Когда и зачем нужна формализация?

• Кто должен тестировать требования?

• Важен ли порядок тестирования?

• Что брать в основу процесса?

• Формализовать можно не всё


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


Success-story


Пример

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


Пример


Пример

1. Сформировали вопросы

2. Через выполняющего роль аналитика задали вопросы заказчику

3. Согласовали итоговый вариант после нескольких итераций

4. Стали реализовывать логику внутри ПО

К моменту ввода системы в эксплуатацию – ошибки не было


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


Материалы

1. К.Вигерс и Дж.Битти. Разработка требований к ПО

2. Анна Абрамова. Что такое Use Case и зачем они нужны?

3. Алексей Федоров. Шагнуть на встречу тестированию требований

4. Сергей Мартыненко.

Написание тестов, как вид тестирования требований

5. Niels Malotaux. Inspection used in various ways

http://www.ozon.ru/context/detail/id/27995134/

http://school.system-analysis.ru/use-case/



http://analystdays.com/ru/talk/36033

https://vimeo.com/13803733

http://sqadays.com/en/talk/43282


Материалы

1. Юлия Нечаева. Тестирование требований: КАК?

2. Андрей Курьян. Метод VCM+

для выявления противоречий в требованиях заинтересованных лиц

3. Сергей Мартыненко. Приоритизация

методов верификации требований

4. Еще несколько презентаций: 1, 2, 3

http://www.slideshare.net/greesha/laf2010-nechaeva

http://www.slideshare.net/greesha/laf2010-nechaeva

http://analystdays.ru/ru/talk/32941





http://www.slideshare.net/VLDCORP/ss-12694550

http://www.slideshare.net/ukryvenka/ss-22861055

http://www.slideshare.net/ISsoft/ss-34333468

Вопросы?

Skype: thaya.tt

email: [email protected]

Education

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