Что такое бизнес требования в тестировании

Как бы банально это не звучало, но большинству людей нравится, чтобы все было просто. Особенно, когда дело касается новых продуктов. По сути, потенциальная ценность, которую ваш продукт или сервис может привнести в жизни в ваших клиентов, не имеет никакого значения, если люди не смогут использовать его так, как этого хочется им, они почти наверняка пройдут мимо и обратят внимание на другие решения.

Напрашивается вывод — прежде чем начинать продавать свой продукт целевым клиентам, вы должны убедиться в том, что они смогут работать с ним так, как и намеревались изначально.

Именно здесь вам может пригодиться пользовательское приемочное тестирование (User Acceptance Testing, UAT). В сегодняшней статье мы расскажем вам, что это такое, когда и как вам следует использовать данный метод и почему он играет столь важную роль при выводе продукта на рынок.

Тестировщик с нуля / Урок 26. Как тестировать требования? Тестирование требований

Что такое пользовательское приемочное тестирование?

Пользовательское приемочное тестирование — процесс, в ходе которого вы просите группу людей использовать продукт, сервис или часть софта с его полным функционалом.

Известное также как бета-тестирование, UAT служит трем основным целям:

1. Определить, работает ли продукт в реальных ситуациях так, как задумывалось при его создании.
2. Определить, были ли обозначены все доступные функции.
3. Проверить продукт на наличие багов и сбоев, которые мешают ему выполнять свои основные функции.

Далее в статье мы еще поговорим о важности UAT, но сперва давайте быстро разберем разные типы такого тестирования.

5 типов пользовательского приемочного тестирования

1. Первый тип, на котором мы и будем фокусироваться в этом посте, — альфа/бета-тестирование. При альфа-тесте роль пользователей на себя берут штатные сотрудники и члены команды разработчиков. А вот бета-тест проводится с участием реальных, специально отобранных пользователей. Ниже — пример лендинга с предложением зарегистрироваться для бета-тестирования Division 2, анонсированного на E3:

Эта страница не очень удачно выглядит в русской реализации, но, тем не менее, она выполняет свою функцию. Быстро и без особых усилий создать свой лендинг пейдж для бета-тестирования вашего нового продукта можно с помощью нашей платформы. Для этого достаточно выбрать любой бесплатный шаблон и адаптировать его под себя:

2. Контрактное приемочное тестирование (contractual acceptance testing) нацелено на то, чтобы проверить, соответствует ли разработанный продукт контрактным требованиям, согласованным всеми заинтересованными сторонами. Обычно такое тестирование используют, дабы убедиться в том, что сторонняя команда разработчиков выполнила свои договорные обязательства.

Тестировщик с нуля / Урок 4 / Тестирование требований

3. Законодательное приемочное тестирование (regulation acceptance testing) позволяет убедиться в том, что продукт соответствует всем законам и предписаниям своей отрасли и юрисдикции. Такое тестирование следует проводить в сферах здравоохранения и финансов, кроме того, с внедрением GDPR на нем должны акцентировать внимание все европейские компании.

4. Операционное приемочное тестирование (operational acceptance testing) сосредоточено на определении эффективности закулисных процессов внутри организации, которые гарантируют людям полноценное использование продукта. С помощью этого типа тестирования оцениваются такие процессы, как онбординг, сбор данных и защитные механизмы.

5. Тестирование по стратегии черного ящика (black box testing) ориентировано на анализ причинно-следственной связи между взаимодействием пользователя с продуктом и результатом, полученным за счет этого взаимодействия. Этот тип тестирования связан с UAT тем, что здесь людям говорят, для чего предназначен продукт, но изучать, как именно он работает, они могут самостоятельно.

Почему пользовательское приемочное тестирование играет столь важную роль

Итак, UAT является неотъемлемой частью процесса создания продукта. Тем не менее, вы должны фокусироваться на таких тестах не только при их фактическом проведении, но и на всех этапах разработки:

Как видно из диаграммы выше, пользовательское приемочное тестирование нацелено на то, чтобы все изначальные требования к продукту были соблюдены.

Думайте о конечном пользователе

Ценность вашего продукта определяется только людьми, которые будут с ним работать.

Хотя это звучит весьма очевидно, в процессе разработки продукта о таком нюансе можно запросто забыть. Не учитывая то, как ваши конечные пользователь будут взаимодействовать с вашим продуктом, вы рискуете столкнуться со многими проблемами или даже отклониться от намеченного пути. И точно также, не зная, чего на самом деле конечные пользователи хотят от вашего продукта, вы рискуете снабдить его совершенно ненужными функциями.

Несмотря на то, что удерживать фокус на клиентах в ходе разработки можно по-разному, акцентируя внимание на UAT, вы гарантированно сможете убедиться в том, что все усилия по вашему продукту делаются с мыслью о конечном пользователе.

Кроме того, это поможет вам сделать процесс разработки менее произвольным, поскольку каждое изменение или улучшение будет сопровождаться вопросом: «Как эта функция поведет себя в ходе пользовательского приемочного тестирования?».

Подтвердите product/market fit

Положительные результаты, полученные бета-тестерами во время вашего UAT, могут подтвердить не только наличие рынка для вашего продукта, но и то, что потребители в рамках этого рынка будут успешно использовать ваше решение.

Когда продукт готов к проведению UAT?

Прежде чем начинать UAT, команда разработчиков должна соблюсти ряд предварительных условий.

Остановимся на этих критериях более подробно.

Бизнес-требования должны быть готовы

Согласно iSixSigma, главным образом документы по бизнес-требованиям создаются, чтобы:

• прийти к согласию между заинтересованными сторонами;
• обеспечить основу, которая бы объясняла поставщику технологических услуг, каким должен быть продукт, чтобы удовлетворить потребности бизнеса и клиентов;
• обеспечить исходные данные для следующей стадии проекта;
• описать, как потребности бизнеса/клиентов будут удовлетворены за счет продукта.

Продукт должен функционировать на своих предельных возможностях

Пользовательское приемочное тестирование не является синонимом функционального теста. UAT не предназначено для выявления сбоев, ошибок, зависаний и прочих проблем.

Вместо этого, с помощью таких тестов вы должны проверять юзабилити продукта, когда он работает так, как вы и задумывали изначально. Иными словами, если на текущий момент ваше решение нуждается в каких-то очевидных доработках, оно не готово к UAT.

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

По ходу разработки продукта вы почти наверняка столкнетесь с перечисленными выше проблемами. Чтобы подготовить свое решение к UAT, ваша команда должна не только исправлять эти просчеты, но и фиксировать их в специальном лог-файле.

Этот лог-файл должен содержать следующую информацию:

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

Такой подход обеспечивает максимальную прозрачность и наглядность в контексте разработки продукта для всех заинтересованных сторон.

Команда по тестированию системы должна дать добро

На данном этапе производственного процесса, когда все остальные критерии уже были соблюдены, команда разработчиков и другие заинтересованные стороны должны подтвердить готовность продукта к бета-запуску для ограниченного количества пользователей.

Зачем нужно пользовательское тестирование: кейс от Feedly

6 шагов успешного пользовательского приемочного тестирования

Процесс UAT включает в себя следующие этапы:

1. Проанализируйте бизнес-требования

Как было сказано ранее, прежде чем переходить к разработке продукта, вам необходимо позаботиться о документации по бизнес-требованиям. Но помимо этих документов, вам нужно собрать следующее:

• Устав проекта
• Бизнес-кейсы использования продукта
• Диаграммы технологических процессов
• Спецификации к системным требованиям (для SaaS-продуктов)

Анализируя эти документы, вы сможете начать разработку тестовых сценариев — важнейшего аспекта всех последующих шагов процесса.

2. Разработайте UAT план

На этой стадии вы определяете такие логистические критерии UAT, как:

• условия входа и выхода (то есть когда продукт готов к UAT и когда тестирование будет считаться завершенным);
• кто будет участвовать в тестировании и какая роль будет отводиться им в течение всего процесса;
• график и продолжительность тестирования;
• как будут собираться, анализироваться и задействоваться тестовые данные.

3. Определите тестовые сценарии и кейсы

Вам нужно будет продумать конкретные задачи для своих бета-тестеров и подготовить учебные материалы, которые бы помогали им пройти этот путь.

По сути, вы должны разрабатывать такие тестовые сценарии так же, как и свой onboarding-процесс. Таким образом вы убедитесь в том, что ваше бета-тестирование соответствует тому, как продукт будет использоваться в реальных условиях.

4. Подготовьте тестовые данные

Разумеется, вы также должны наладить процесс, который бы позволял вам эффективно собирать и подготавливать тестовые данные. Кроме этого, вам нужно быть уверенными в том, что используемая вами информация всегда будет оставаться конфиденциальной (особенно учитывая то, что GDPR уже вступил в силу в Европе).

5. Проведите тест

В ходе тестирования члены QA команды работают с бета-пользователями, чтобы завершить обозначенные тестовые задачи. Как только юзер достигает точки выхода, его просят оценить полученный опыт как позитивный или негативный.

Если большая часть ответов оказывается положительной, команда может уверенно двигаться вперед и выводить продукт на рынок, создав посадочную страницу, открытую уже для всех желающих. Если же это не так — разработчикам придется внедрять в продукт необходимые изменения.

Также стоит отметить, что хотя к этому моменту ваш сервис уже должен нормально функционировать, во время UAT ваши бета-тестеры могут столкнуться с непредвиденными проблемами. Если это произойдет, вам нужно будет приостановить тестирование и возобновить его после устранения неполадок.

6. Подтвердите достижение бизнес-целей

Как только бета-пользователи дадут вам положительную обратную связь, вам нужно будет подготовить документацию, которая послужит официальным сигналом для вывода вашего продукта на рынок.

Эта документация включает:

• план тестирования
• UAT сценарии и тестовые кейсы
• результаты пользовательских тестов
• лог-файл с проблемами (то есть баги, сбои, неполадки и т. д.), обнаруженными в ходе разработки и тестирования продукта

Затем эти документы представят на встрече по UAT, где будут присутствовать все заинтересованные стороны. Помимо рассмотрения самих документов, участники собрания должны будут убедиться в том, что продукт действительно готов к запуску и что закулисные бизнес-процессы компании гарантируют его стабильную работу.

По материалам: fieldboom.com, Источник картинки: deadheading

Источник: lpgenerator.ru

Home

Критерии качества требований

Что делает требования хорошими? BABOK 3.0 предоставляет девять характеристик качества требований к ПО, можно использовать их, как чек-лист при написании или тестировании требований:

• Атомарность
• Полнота
• Краткость
• Консистентность
• Выполнимость
• Приоритизированность
• Тестируемость
• Недвусмысленность
• Понятность

Давайте рассмотрим некоторые критерии качества требований подробнее, а также определим, как приблизиться к идеалу.

Атомарность

Атомарное требование — это такое требование, которое нельзя разбить на более детальные требования (которые при этом не потеряют завершенности — то есть, требование, что юзер может залогиниться, введя имейл и пароль, нельзя разбить на 3 юзер стори (пользовательские истории): про поле для имейла, поле для пароля и кнопку входа).

Почему важно, чтобы требования к программному обеспечению были атомарными? Чтобы:

• правильно приоритизировать (сложно приоритизировать юзер стори, которая включает в себя создание, редактирование и удаление поста. Но если разбить ее на 3, становится уже намного легче — из этого набора в МВП явно может входить не всё);
• трассировать (например, ставя зависимость от очень большого требования, в будущем возникает путаница — от какой именно части зависимость?);
• легче разрабатывать (меньше возможностей напутать/пропустить что-то, когда требование небольшое и простое);
• требование быстрее попадет в тестирование — да, это очень важно, QA меня поймут.

Чтобы требования были атомарными, их нужно уметь правильно декомпозировать (что такое декомпозиция, писала здесь).

Полнота

Полнота — очень важная характеристика качества требований, которая достойна отдельной статьи.

Полнота/подробность требований зависит от нескольких факторов, например, от «взрослости» команды. Например, команда джуниоров может нуждаться в описании того, что такое «спецсимвол» и какие из них можно использовать в пароле. Или, например, что делать, если в поле юзернейм пользователь не ввел ничего, кроме нескольких пробелов: мы такое принимаем вообще, или нужно как-то пробелы обрезать и считать поле с одними пробелами незаполненным?

Набор требований является полным тогда и только тогда, когда он описывает все важные требования, интересующие пользователя, в том числе требования, связанные с функциональными возможностями, производительностью, ограничениями проектирования, атрибутами или внешними интерфейсами (IEEE 830-1993, § 4.3.3, 1994).

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

• система не будет целостной (например, определенное поле, из-за ненадобности, убрали по всей системе, кроме пары страниц, или, наоборот, что-то добавили, а в экспорт данных добавить забыли);
• команда не реализует специфический кейс и система «упадет» во время его выполнения;
• команда реализует кейс не так, как хотелось бы клиенту/вам/было бы правильно для продукта («додумает» требование сама);
• возникновение множества вопросов у команды (во время реализации и тестирования);
• какие-то нефункциональные требования будут не учтены, и, например, сервер упадет, когда 100 человек одновременно зайдут на сайт.

Добиться полноты требований помогают:

• понимание нефункциональных требований (какие вообще есть, какие применимы к вашему проекту/продукту/юзер стори);
• прототипирование (когда продумываешь интерфейс, начинаешь рассматривать фичу под другим углом);
• диаграммы (будь то активити диаграмма (UML), BPMN, обычный флоучарт или даже ERD (UML) (список можно продолжать) — они все заставляют подумать о различных аспектах требований и дополнить их);
• декомпозиция (когда разбиваешь эпик на истории и пишешь критерии, есть возможность «выловить» что-то еще);
• трассирование требований (или перелинковка в системе управления требованиями — когда есть трассирование, тогда знаешь, что изменения в части А затронут часть Б и требования к системе будут полнее);
• конечно, командная работа — брейншторминги с командой, груминги, обсуждения с UX командой — все это заполняет пробелы и наталкивает на интересные мысли;
• фоллоу-апы звонков и правильные цепочки переписок с клиентами — правильная организация значительно снижает шансы упустить важные детали или забыть, что что-то уже изменилось;
• ревью требований другими аналитиками;
• тестирование требований (QA пишут кейсы/чеклисты тестирования на стори, которые вы считаете готовыми, и находят пробелы).

Хорошие требования — это такие требования, которые не нужно уточнять, то есть, есть все необходимые детали (но без излишней детализации).

Хотите стать бизнес-аналитиком?

Я готовлю онлайн-курс для тех, кто хочет войти в ИТ через БА или перейти в БА внутри ИТ. Когда он выйдет, я сразу оповещу вас!

Однозначность

Хорошее требование = однозначное требование.

Однозначность — это важный и сложный критерий качества требований. У каждого человека свой опыт и свой набор знаний, что накладывает определенный отпечаток на восприятие информации. Поэтому требования к ПО нужно стараться писать так, чтобы они были максимально однозначными и понятными для любого человека (то есть, понятными не только аналитику 🙂 ).

Любой человек, читающий требование, должен понимать его так же, как и тот, кто его писал.

Представьте кофе. Представили?

Кто-то представил эспрессо, кто-то американо, кто-то пьет с молоком и представляет латте, а кому-то жарко и хочется освежиться айс латте.

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

• команда реализует не то, что нужно и это уйдет на прод/на демо (менее критично, чем на прод, но = потери времени и порча репутации);
• команда реализует не то, что нужно, но QA отловят, и заставят переделать (потери времени);
• начнутся споры, а как же должно работать, у каждого будет свое мнение, и хорошо, если БА работает на проекте и может разъяснить, а не написал свои юзер стори и ушел на другой проект;
• потери от неоднозначно описанных нефункциональных требований могут быть гораздо больше. Например, в требованиях можно написать «система должна быть секьюрной», имея в виду учет первых трех угроз из списка OWASP, а клиент может ожидать совершенно другого подхода к безопасности, на 100000 $ «серьезнее»)

Acceptance criteria (приемочные критерии к юзер стори) типа «система работает быстро», или «интерфейс понятен пользователям» — не измерить, поэтому они неоднозначные. У каждого свое «быстро» и «понятно».

К «неоднозначным» моментам можно также отнести следующие моменты (если они не описаны — реализация может вас удивить):

• значения по умолчанию;
• формат полей;
• допустимые символы;
• реакцию системы на негативные сценарии.

Неоднозначность можно отловить:

• самостоятельно, читая требования через пару дней после написания (перечитывать, «выпав» из контекста);
• проговорив требования с клиентом/продакт оунером;
• обсуждая юзер стори (например) с командой;
• попросив поревьюить требования;
• на демо, когда клиент говорит «ЧТО ВЫ ТАКОЕ СДЕЛАЛИ, Я НЕ ЭТО ПРОСИЛ. «.

То есть: качественные требования должны быть понятны всем одинаково.

Выполнимость/осуществимость

Не все требования (как нефункциональные, так и функциональные) возможно выполнить. Некоторые требования невыполнимы, т.к. нелогичны. Некоторые — т.к. на данный момент нет инструментов, которые позволяли бы его выполнить с использованием адекватного количества ресурсов.

Когда-то на груминге мы с командой обсуждали добавление небольшой детальки, которая, казалось, важна для улучшения юзабилити.

— Это невозможно сделать! — сказал мой молодой коллега.

— Ну почему же, это вполне возможно, — возразил более опытный разработчик. — Нужен примерно год.

Иными словами, некоторые требования условно считаются невыполнимыми, т.к. баланс между ценностью и ресурсами является неразумным в данных условиях (у каждого эти условия свои).

Непротиворечивость

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

Например, если в dаta dictionary отмечено, что поле Имя — обязательное, а в user story написано, что оно опционально — требования к системе неконсистентны (не непротиворечивы).

Такое обычно происходит, когда:

• бизнес-аналитик забывает, что что-то уже продумал/описал и делает это по-новой в другом месте;
• когда требование меняется, но бизнес-аналитик изменяет его не везде, где оно описано;
• когда бизнес-аналитик невнимателен к граничным значениям — например, приемочные критерии (acceptance criteria) противоречат друг другу — в одном, возраст=14 — уже подростковый. То есть, 14 относится и к одним, и к другим, чего, скорей всего, автор не добивался;
• когда новый бизнес-аналитик на проекте упустил/не знал про какие-то детали реализации, особенно, когда они не описаны или их сложно отследить в системе управления требованиями;
• когда требования изменили, а дизайнеру сказать забыли.

Также, требования не должны противоречить «вышестоящим» требованиям — например, функциональные требования должны быть консистентны с требованиями пользователя, требования пользователя — с бизнес-требованиями.

Проверить требования на непротиворечивость можно с помощью ревью — собственного/ревью командой.

Вывод:
Для того, чтобы проверить, насколько хороши требования (ваши или БА на вашем проекте) — воспользуйтесь критериями качества требований, которые я описала выше.

Что еще должен уметь бизнес-аналитик — читайте в статье.

И подписывайтесь, чтобы не пропустить новые статьи о бизнес-анализе.

Sign up for more like this.

Enter your email

Что такое Agile и какая роль бизнес-аналитика в Agile?

Что такое agile? Какие существуют agile фреймворки? Какая роль бизнес-аналитика в agile? Что такое юзер стори? Об этом и не только, пойдет речь в этой статье. Agile – это методология управления проектами, которая позволяет быстро и гибко реагировать на изменения в требованиях и условиях работы.

Agile и означает — гибкий. В

Apr 1, 2023 7 min read

Как Стать Бизнес-Аналитиком в ИТ в 2023 Году?

Спрос на бизнес-аналитиков растет, все больше компаний признают необходимость иметь специалиста, который может анализировать и интерпретировать требования, общаться с бизнесом и техническими командами, анализировать зависимости, проводить исследования. Бизнес-аналитики также необходимы для выявления областей, требующих улучшения в бизнес-процессах и системах, а также для облегчения коммуникации между различными отделами и заинтересованными сторонами

Mar 18, 2023 11 min read

Что должен уметь бизнес-аналитик?

Один из лучших ответов для многих вопросов на собеседованиях — it depends. Ответ на вопрос, что должен уметь бизнес-аналитик, не будет исключением. Это зависит от компании, проекта, типа и фазы продукта, заказчиков. Кроме чтения книг по этой теме, я еще периодически изучаю рынок, локальный и не только — какие требования

Источник: www.thebagirl.com