Feature Injection: работаем с требованиями

15. Step III: Scenario Creation In order to increase sales of our products: As a customer I should be prompted for my registration details So that I can receive the list of related (to my first purchase) products.

16. One more example … “As a user I want captcha, so that …” “In order to stop bots spamming my site As a forum moderator I want users to fill in a captcha”

17. THANK YOU!

Editor's Notes

Всем привет! Спасибо, что заглянули. Следующие 20 минут развлекать вас буду я. Кстати, меня зовут Алла. Наверное, каждый из вас уже успел обратить внимание на то, что написано за моей спиной. Говорить сегодня мы будем о требованиях, а это довольно интересная и я бы даже сказала полезная тема.И сразу вопрос: как вы считаете, всегда ли присутствуют требования?Часто можно услышать,что «я тестирую без требований» и т.п.….Требования есть всегда! Главное – это научиться их готовить.
Мой путь в тестировании начался с того, что я попала на медицинский проект, где была куча требований, стандартов, аудитов и так далее. И теперь при первом упоминании о требованиях у меня сразу возникает ассоциация: требования – это толстенная спека с кучей букв внутри! Может сложиться мнение, что проработка требований не приносит никаких ощутимых результатов. Зачастую аналитики сидят, пишут какие-то доки... а тут нужно писать код и заносить баги. Мы и без них справимся. Они только отнимают время. Анализ является неотъемлемой частью в жизни каждого проекта. Команда должна понимать, что она разрабатывает и в каком порядке должны предоставляться результаты разработки. Тут-то и возникает вопрос о качестве требований, о том, как нужно работать с требованиями на проекте, и как “правильные” требования могут облегчить работу тестировщика в частности.
Как вы думаете, каким ПО заказчик останется доволен?Ответ прост: тем, которое полностью удовлетворяет его потребности. Если говорить на формальном языке, то это такое ПО, в котором модель реализации полностью совпадает с бизнес-моделью. И эта бизнес-модель должна быть ясна как для разработчиков, так и для заказчика.Наверное, многие сталкиваются с проблемой, когда заказчик нечетко формулирует требования или очень часто их изменяет. При этом ему кажется, что изменения минорны, но, если вникнуть в детали, эта минорность чревата переработкой большого куска функционала. Причина этого проста: изначальном не были четко выявлены требования и не был произведен их последующий анализ.Есть и такие случаи: бизнес приходит уже с наполовину сделанным продуктом вместо того, чтобы изначально сформировать четкое видение того, что он хочет в результате. Например, бизнес находит thirdparty систему, которая якобы удовлетворяет всем его требованиям, но на самом деле просто он не знает всех тех критериев, которым должна соответствовать система. И начинаются различные комбинации по прикручиванию системы, затем только задается вопрос, насколько она удовлетворяет требованиям бизнеса. Проще было бы, если бы все требования изначально были выявлены и под них уже подбиралась бы система.
Вот тот перечень проблем, с которыми сталкивается множество проектов. Как вывод, нужно правильно организовать работу по выявлению требований, и в этом полезной может оказаться техника FeatureInjection.FeatureInjection позволяет описать систему, как совокупность примеров (сценариев поведения), а не набора “thesystemshall...” утверждений, для этого FeatureInjection использует примеры для того, чтобы описать, что необходимо разработать, а это в свою очередь улучшит понимание того, что является результатом, какова ценность проекта.
Техника Feature Injection состоит из трех шагов:1.Поиск целей проекта2. Сбор требований3. Разработка примеров (сценариев)Рассмотрим каждый из шагов подробнее.
Всегда проще работать, когда ты осознаешь то, что и зачем делаешь. Поэтому важность правильной постановки целей нельзя оспорить.Именно это и является первым этапом проработки требований согласно Feature Injection.Многие проекты начинаются с реализации запросов на дополнительную функциональность, и, как результат, команды преследуют неясную им бизнес-цель.Например, нам может поступить запрос реализовать более красивый UI. Корень этого запроса скрывается в том, что бизнес хочет увеличить степень удовлетворенности работников, что за собой влечет необходимость уменьшить текучку кадров для того, чтобы снизить операционные риски. Вот такие уровни может содержать запрос на изменение UI. Когда четко не определены и не доведены до ведома всех вовлеченных в проект людей цели проекта, то существует очень большая вероятность того, что эти цели никогда не будут удовлетворены на 100%. Не зная целей, команда так же не сможет предложить альтернативный путь их удовлетворения, который может оказаться легче, дешевле и эффективнее.
Техники для выявления целей проекта:1. Powerful QuestionsТехника состоит в том, что необходимо задавать как можно больше открытых вопросов заказчику:“ What is the most important thing the system should do?”“What is the next most important thing the system does not yet do?”“If we were to switch of the system, where and what would be the biggest impact?”Вопросы такого рода зачастую ведут к определению цели создания системы.2. PersonasВыявление типичных пользователей системы и их сценариев поведения.3. Последнее, это скорее не техника, а совет “Yоuain`tgonnaneedit (YAGNI)”“Always implement things when you actually need them, never when you just forsee that you need them”
Как только были определены цели проекта, можно смелоприниматься за сбор требований, то есть за создание списка фич, которые будут удовлетворять этимцелям.
Классическое представление о системе следующее: что-то поступает на входПроисходит магияЧто-то получается в результатеС чего бы вы начали анализ системы: со входа, «магии» или выходов?Самая большая ошибка при сборе требований - это начало анализа со входов системы.Входы в систему сами по себе не несут никакой ценности, только их связь с выходами. Начало разработки с определения входов в систему - это бесконечный цикл поиска ответов на вопрос “Что еще нужно?” и трата большого количества времени на анализ с целью все же найти то, что нужно для реализации проекта. Это типичный сценарий “аналитического паралича”.
Что нам может помочь на этапе сбора требований:1. Техники UML2. EffectMapping. Effectmaps это диаграммы (карты), основной целью которых является преобразование целей проекта в требования. Карты помогают командам сфокусироваться на бизнес целях при планировании скоупа проекта. Это отлично подходит для flow-based методов разработки, таких как Канбан.
Когда требования к системе уже выявлены, последним этапом является формализация этих требований.Feature Injection гласит, что нужно разрабатывать сценарии.Какая польза от сценария? Сценарий - это по сути пример того, как должна работать система. Отличие сценария от требований состоит в следующем: не все представители заказчика технически грамотные люди, которые могут сразу и четко определить все usecases работы системы и сформулировать их. Им проще говорить в терминах примеров: предоставлять сценарии, в которых система выдает желаемые результаты. Эти сценарии потом становятся приемочными тестами.
А теперь давайте попробуем это все на практике. За основу возьмем книжный интернет магазин. Допустим, у нас есть требование, описанное посредством User Stories (стандартный подход Scrum-методологии):“As a sales managerI want customers to register in the systemSo that we increase sales of our product”Проблема UserStories в том, что фокус делается на роли, только затем делается попытка определить цель.Когда мы приступаем к анализу требования, первое, что нас интересует - это цель, значимость для бизнеса, которое излагается в этом требовании.Его проблема состоит в том, что неправильно определена роль, чьи потребности нужно удовлетворить. В данном случае приоритетен salesmanager, хотя должен быть customer.. Давайте попробуем применить подход Feature Injection поэтапно.
Первый этап: Определение целиДавайте подумаем над целью …Как видим из user story цель – это «Increase sales of products»
Этап 2: давайте попробуем проанализировать требованияЯ выберу технику Effect MapsТеперь последовательно ответим на вопросы Why? Who? How? What?Why (we need to follow this goal) – to turn our one-time-customers into loyal onesWho (will be affected) – customerHow (he will be affected)– he will receive list of related products to his first purchaseWhat (should we do to achieve goal) – customer e-mail details should be provided in our system (wee need his registration)
А теперь попробуем соединить результаты первого и второго этапа вместе.Вот и требование обрело весомость и самое главное в нем правильно определена роль, потребности которой нужно удовлетворить.Это требование с легкостью может быть трансформировано в приемочный тест.
Ещеодинпример.Все не раз регистрировались на различных сайтах, и хорошей практикой защиты от ботов является наличие капчи на форме регистрации. Давайте-ка представим, как скорее всего выглядит требование для реализации капчи:“AsauserIwantcaptcha, sothat…” Как юзер я 100% не хочу заполнять бессмысленную с моей точки зрения капчу! Ведь это просто трата времени. Давайте попробуем немножко изменить формулировку требования:“In order to stop bots spamming my siteAs a forum moderatorI want users to fill in a captcha”Вот и требования обрело сразу весомость и смысл.

Feature Injection: работаем с требованиями

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (18)

Similar to Feature Injection: работаем с требованиями

Similar to Feature Injection: работаем с требованиями (10)

More from SQALab

More from SQALab (20)

Recently uploaded

Recently uploaded (20)

Feature Injection: работаем с требованиями

Editor's Notes