---
# System prepended metadata

title: Ревью эпиков

---

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

## Проблема 

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	Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.

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

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

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

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

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

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

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

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

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