5.1 Работа с требованиями для тестировщика
Требования - самый главный документ в сфере IT!
Любой проект, который планируется реализовать, начинается с требований, это самый главный документ который используется в процессе разработки программного продукта. Это тот документ, на который все опирается и с которым будет позже сравниваться наш продукт. От того на сколько четко и грамотно они будут сформулированы во многом зависит успех нашего продукта.
Что такое требования?
Требования — это документ, описание того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Выделяют 4 уровня требований:
1. Уровень бизнес требований
Уровень бизнес требований – цель, ради которой создается продукт (для чего он нужен заказчику, какая польза, как получим прибыль).
К примеру, фирма создает чат для своих сотрудников или, к примеру интернет-магазин для продажи товара, которая она производит.
Данные требования не относятся напрямую к реализации проекта, а в первую очередь отражают цели бизнеса.
Бизнес-требования содержат следующие понятия:
- Причины инициации проекта – например у компании проблема с реализацией товара в своем регионе, и она решила выйти за его пределы, для этого решила создать свой интернет-магазин, для того, чтоб пользователи с других регионов могли заказать товар.
- Цели, которые должны быть достигнуты в результате разработки данного продукта – к примеру увеличить количество сбыта продукции и заключение контрактов с потребителями из других регионов
- Концепция продукта — сжатое описание конечного продукт, который выполнит заданные цели. Например, интернет-магазин который будет покрывать потребности пользователей в конкретной стране или регионе.
2. Уровень пользовательских требований
Уровень пользовательских требований - задачи, которые пользователь может выполнять с помощью продукта (регистрироваться, общаться, искать информацию о продукте)
Пользовательские требования определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Они пишутся простым естественным языком, без погружения в сами процессы.
Пользовательские требования содержат в себе:
- цели и задачи пользователей
- пользовательские истории или сценарии, так называемые user story и user case, о которых мы поговорим далее
- описание ролей и доступов
К примеру, в банках очень много должностей – менеджеры, специалисты, казначеи, начальники отделов и т.д, у банка есть свои программы, в которых у каждого из этих сотрудников будет своя роль, свой доступ, на те документы, задачи, заявки, справочники и т.д, к которым они будут иметь доступ.
3. Функциональные требования
Функциональные требования – что система должна и не должна делать?
Здесь, в отличии от пользовательских требований, описание идет уже на профессиональном языке и более детально.
Указывается перечень функционала, который должна выполнять система, как система реагирует на те или иные входные данные, как она ведёт себя в определённых ситуациях и т.д.
Рассмотрим на примере Видеохостинга, то есть сервиса, на котором мы можем просматривать и загружать видео (к примеру YouTube). Если в пользовательских требованиях будет описано следующее «должна быть возможность загружать видео на платформу», то в функциональных требованиях будет написано «Должна быть возможность подгружать видео в следующих форматах, далее пойдет описание форматов, в случае попытки загрузки файлов некорректного формата выдавать предупреждение, размер файлов может быть в пределах, далее идут границы размера файла, в случае превышение размеров выдавать предупреждение и т.д
4. Нефункциональные требования
Нефункциональные требования – как система должна это делать?
Сюда, к примеру можно отнести характеристики нашего продукта по производительности, то есть какую нагрузку он может выдерживать. Так же надёжность, время ответа системы и т.д.
Основные пути получения информации для составления требований
- Интервью с заказчиком или пользователем
- Наблюдение за продуктами Заказчика или конкурента
- Самостоятельное описание
Примеры получения информации для требований
1. Интервью с заказчиком или пользователем
Наш Руководитель проекта, он же проджект-менеджер, и бизнес-аналитик встречаются с заказчиком и обсуждают с ним требования к продукту. Обсуждают для чего продукт создан, какой он будет нести функционал, как заказчик планирует получать прибыль, какие задачи сможет решать пользователь с помощью этого продукта, на каких платформах и системах будет запускаться наш продукт.
- основная цель разработки данного продукта – это создание платформы для общения, с возможностью обмена медиа файлами, созданием групп для общения и обмена данными
- прибыль заказчик может получать на основе платной регистрации, если такая имеется, встроенной рекламы, продажи подписок на музыку или отключение рекламы и т.д
- возможность запуска нашего приложения на ПК, на мобильных устройствах, в разных браузерах
Все эти пункты и не только описываются в требованиях
2. Наблюдение за продуктами Заказчика или конкурента
Мы так же можем обратить внимание на уже созданные продукты нашего заказчика, если таковы имеются и подчеркнуть из них информацию, например оформление. Так же рассмотреть основных конкурентов, которые уже реализовали подобный продукт. Например, мессенджеры WhatsApp или Viber, мы видим что кнопка ответа на звонок зеленая, а сброса красная, большинству пользователю уже интуитивно знакома такая особенность, поэтому нам выгоднее использовать ее в своем продукте, так как пользователь уже привык к этому.
3. Самостоятельное описание
Это составление требований на основе опыта команды, которая уже создавала подобные продукты
Атрибуты требований:
- Корректность — точное описание разрабатываемого функционала.
- Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
- Недвусмысленность — требование должно содержать однозначные формулировки.
- Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
- Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.
- Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
- Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
- Атомарность — требование нельзя разбить на отдельные части без потери деталей.
- Модифицируемость — в каждое требование можно внести изменение.
Способы представления требований:
1. Use case diagram
Use case diagram – схема, где изображены возможности каждого из ролей в системе: админа, пользователя и т.д, которые описывают варианты взаимодействия между пользователем и программным обеспечением;
2. User story
User story – пользовательское-ориентированное описание целей, которые люди смогут достичь, используя наш продукт, написанный повседневным языком.
Я как ___________, хочу ____________, для того, чтобы ___________.
Как <пользователь> я хочу <действие> для того, чтобы <цель>.
Например:
Как <пользователь> я хочу <регистрироваться онлайн> для того, чтобы <регистрироваться быстро и снизить бумажную работу>
Как <пользователь> я хочу <получить такую функциональность которая позволяла бы мне сделать следующее>:.
Должны быть критерии приемки – что должно быть сделано, чтоб критерии были реализованы. Тестировщик должен придумать тест-кейсы чтоб проверить данные требования.
3. UI mockup
UI mockup -шаблоны нашего UI (U(ser)I(nterface))
4. Спецификация
Спецификация – в текстовой форме, структурированный набор требований к программному обеспечению и его внешним интерфейсам. Предназначен для того, чтобы установить базу для соглашения между заказчиком и командой разработки о том, как должен функционировать программный продукт. Уклон сделан в техническую сторону.
Требования к продукты будут постоянно обновляться, у заказчика будут постоянно появляться новые пожелания к улучшению продукта и к реализации нового функционала. При это первоначальные требования будут часто обновляться, а как следствие должна обновляться и тестовая документация, о которых мы поговорим в следующих видео.