# Практика подготовки тестовой документации

Задачу по подготовке тестовой документации к фиче условно можно разделить на три этапа:

* Действия перед написанием тестовых артефактов
* [Подготовка тестовой документации](https://docs.gitlab-dev.ispsystem.net/onboarding/docs/testers/process#2-подготовка-тестовой-документации) (Процесс подробно описан в онбординге для QA)
* Ревью тестовой документации

## Перед написанием тестовых артефактов

Необходимо создать следующие задачи в свимлейне с фичей (если они ещё не созданы):

1. **"Тестовая документация - [Название фичи, для которой она пишется]"**.
* Навесить тег QA на задачу;
* указать оценку задаче (сколько ресурсов займет задача).
* далее в этой задаче нужно будет указать ссылки на готовую тестовую документацию.

1. **"Чек-лист тестирования для разработчика"**
* Навесить тег FE на задачу (реже BE, если чек-лист будет написан для бекэнда).
* далее в этой задаче нужно будет написать готовый чек-лист для разработчика.

## Ревью тестовой документации

После завершения подготовки тестовой документации задачу нужно перенести на доске `youtrack` в колонку "Подлежит проверке" и добавить тег `#Checklist`. Тогда настроенный бот автоматически сформирует и отправит сообщение команде в канал mattermost для тестировщиков DCI и Ксюши [DCI Checklist](https://im.astralinux.ru/ispsystem/channels/dci-checklist).
Сообщение содержит ссылку на данную задачу в `youtrack` с описанием и указанными ссылками в описании.

**Чтобы процесс ревью проходил регулярно и своевременно предлагается выстроить следующий процесс:**

1. **QA1** создает ToDo с просьбой поревьювить его артефакты, прикрепляя ссылку на сообщение , и призывая ревьюверов (всех QA команды, далее **QA2** и **QA3**) - на каждого ревьювера нужно кинуть ToDo.

:::info
:warning: Если ревью требует срочности, то навешиваем на сообщение эмодзи с мигалкой :rotating_light:.
:::

1. **QA2** и **QA3** в тот момент, когда идут ревьювить артефакты, нажимают в своих ToDo кнопку добавления в свой лист.
1. **QA2** и **QA3** переходят по предоставленным ссылкам и отписывают в тред сообщения документации свои замечания и пожелания с упоминанием **QA1**.
1. После того, как все замечания и комментарии отписаны, **QA2** и **QA3** с чувством выполненного долга нажимают Done в соответствующем ToDo.
1. **QA1** вносит правки в свои артефакты и отписывает итоги правок в тот же тред, и затем навешивает ToDo на ревьюверов **QA2** и **QA3**.
1. **QA2** и **QA3** ставят на первое сообщение эмодзи зеленой галки :white_check_mark: если считают, что тестовые артефакты корректны и больше не нуждаются в исправлении.
Если же они так не считают, то обсуждение продолжается в этом треде до тех пор, пока не будет поставлена зеленая галка на первое сообщение от всех задействованных ревьюверов (по такому же принципу как описано выше).
1. В том случае, если ToDo были созданы, но на них никак не отреагировали выбранные **QA2** и **QA3** (не закрыли), то **QA1** для этих ToDo тыкает Bump, таким образом, напоминая о себе.

### **Время реакции ревьюверов:**

* Если ревью требуется срочно (на сообщении стоит эмодзи с красной мигалкой) - 3 часа;
* если срочности нет - 1-2 рабочих дня, учитывая время отправки документации на ревью (а также загруженность и приоритеты задач команды).
:::info
:warning: **#нужнапомощь #естьсомнения**

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

**После завершения процесса ревью** нужно добавить в UD фичи ссылки на тестовую документацию для тестировщиков, и на чек-лист задачи youtrack для разработчиков. Тестовая документация готова!:handshake: