# Ревью эпиков

## Проблема

1. Тестировщики не проводят ревью требовани в эпиках
Причина:
1.1 Они не видят эпики которые в разработке
1.2 Постановщики задачи не приглашают тестировщика на ревью

2. В ходе ревью на финальном этапе тестирования находим расхождения требований и макетов
- Пример: https://gitlab.sima-land.ru/groups/dev-dep/dev/-/epics/561#note_949598

## Решение

И наше любимое, создаем 2 лейбла

- QA|in review - ставит ПМ когда Epic готов к ревью
- QA|approved - ставит тестировщик когда провел анализ требований

### Иделаьный процесс
1. ПМ создает epic, закидывает на ревью другим ПМ, они поставили палец вверх, далее ПМ отправляет в TODO и кидает лейбл QA|in review, далее Тестер и Лид смотрят, Тестер ставит QA|approved, Лид пишет коммент что все ок/или же ставит задачку на разработку(это и означает что он со всем согласен)
### Исключения
2. ПМ создает epic, закидывает на ревью другим ПМ, они поставили палец вверх, далее ПМ отправляет в TODO и кидает лейбл QA|in review, далее Тестер и Лид смотрят, Тестер ставит QA|approved, Лид говорит что это дичь не реализуемая, как только он написал коммент и были внесены правки в эпик то ПМ снова ставит лейбл QA|in review и Тестировщик снова проверяет

## Правила таковы:
- Без установки тестировщиком лейбла QA|approved Лид команды разработки не может заводить задачку на разработку
- Все правки эпика ПМ должны сопровождаться сменой лейбла на QA|review если ранее был указан лейбл QA|approved

## Что включает в себя анализ требований

Атрибуты требований:

1 Корректность — точное описание разрабатываемого функционала.
2 Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
3 Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
4 Недвусмысленность — требование должно содержать однозначные формулировки.
5 Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
7 Атомарность — требование нельзя разбить на отдельные части без потери деталей.
8 Модифицируемость — в каждое требование можно внести изменение.
9 Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.

### Почему это так важно и для кого это нужно

Для менеджера:

- Увеличивается скорость разработки — меньше одинаковых вопросов к автору требований, меньше переделок после разработки
- Он раньше получает информацию, важную для принятия решений
- Выше качество продукта — некоторые ошибки требований очень дорого или невозможно исправить после разработки

Для автора требований:

- Обратная связь сразу, пока он ещё в контексте задачи
- Дополнительная информация о краевых случаях и рисках
- Меньше одинаковых вопросов

Для разработчика:

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

Для тестировщика:

- Возможность влиять на проект в самом начале. Часто тестировщики знают, как продукт работает на самом деле и какие есть подводные камни
- Меньше багов на этапе тестирования продукта
- Понятнее, что должно получиться и как это проверять. Следовательно проще разрабатывать тестовую документацию.