Use Case
(вариант использования, ВИ, Прецедент, юскейс)
Сценарная техника описания взаимодействия.
С помощью Use Case может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний в реальной жизни.
Job story
Фреймворк для компоновки данных о потребности человека:
Ситуации, в которой возникла проблема (Ситуация);
Что, по мнению человека должно произойти, чтобы проблема решилась (Мотивация);
Что человек получит, когда проблема будет решена (Ауткам).
User Story
Это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
Текст самой user story должен объяснять роль/действия юзера в системе, его потребность и профит, который юзер получит после того как история случится
К примеру:
Как, <роль/персонаж юзера>, я <что-то хочу получить>, <с такой-то целью>:
Как посетитель сайта я могу войти в систему под ранее созданной учетной записью, для последующей работы.
User Story Mapping
Инструмент целостного проектирования продукта на основе пользовательского пути.
INVEST
Метод проверки user story
Систематический подход, используемый для оценки потенциальных инвестиционных возможностей и принятия обоснованных инвестиционных решений.
Он обеспечивает структурированный каркас для анализа инвестиций на основе их привлекательности и соответствия инвестиционным целям.
I (Independent) – ваша история не зависит от выполнения других историй
N (Negotiable) – вы уже несколько раз обсудили историю
V (Valuable) – реализованная история принесет реальную бизнес-ценность
E (Estimable) – возможно оценить трудозатраты, необходимые для выполнения истории
S (Small) – историю можно реализовать за одну итерацию
T (Testable) – есть понятные критерии приемки и тестовые сценарии для проверки реализации
Given-When-Then (GWT)
Подход, который используется для приемочных тестов
Given описывает что «дано», т.е. состояние системы в начальный момент времени
When задает непосредственно триггер, который должен привести к результату. Чаще всего это какое-то действие пользователя.
Then определяет результат этого действия, т.е. является критерием приемки.
Acceptance test driven development (ATDD)
Это подход к разработке программного обеспечения, основанный на комплексной итеративной модели разработки и создании автоматизированных приемочных тестов.
Behavior-Driven Development (BDD)
Разработка на основе поведения (Behavior-Driven Development, BDD) — это практика Agile-тестирования, когда в первую очередь проводятся проверочные испытания, которые обеспечивают встроенное качество за счет определения (и, потенциально, автоматизации) тестов до или как часть определения поведения системы.
BDD — это совместный процесс,который создает общее понимание требований между бизнесом и Agile-командами.
Его цель — помочь в управлении разработкой, уменьшить количество переделок и увеличить поток
Arrange – Act – Assert (AAA)
«Настрой – действуй – проверь» – способ структуризации тест-кейсов.
USR (user-system-risks)
USER — Что пользователь хочет сделать с системой?
SYSTEM — Что должна делать система?
RISKS — Какие проблемы могут возникнуть?
Example mapping
Коллаборативный метод, используемый в Agile-разработке программного обеспечения для разработки и уточнения требований и функциональности продукта. Он основан на итеративном процессе разработки и состоит из групповых дискуссий и моделирования примеров использования продукта.
Project canvas
Шаблон, который позволяет оформить основные гипотезы продукта на одном листе. Один из способов оформить VISION продукта.
Состоит из 9 блоков:
целевая аудитория (ЦА)
ключевые проблемы ЦА
уникальное ценностное предложение (УЦП)
суть решения
каналы взаимодействия с ЦА
как формируются доходы
как формируются расходы
ключевые метрики
неконкурентное преимущество.
Gantt diagram
Инструмент визуализации процесса выполнения проекта. Она представляет собой горизонтальную полоску, разбитую на отрезки, каждый из которых соответствует определенной задаче или этапу проекта.
Вертикальная ось показывает время, распределенное по периодам или дням.
Test Case
Форма записи проверки, которую проводит тестировщик. Это алгоритм действий, по которому предполагается тестировать уже написанную программу.
В нём подробно прописаны шаги, которые нужно сделать для подготовки к тесту, сама проверка и ожидаемый результат.
Prio
Сокращение от слова «приоритет». В рамках управления проектами и задачами, термин «prio» (или «приоритет») обозначает уровень важности задачи или требования.