1. База (Общие правила)

· Единые критерии: «Что такое баг?», «Что такое готово?» (DoD) — определить и утвердить до спринта. · Раннее вовлечение: QA читает документацию/requirements до старта разработки, а не в момент сдачи. · Единый язык: Один трекер (Jira/Trello), одни приоритеты (Critical/Major/Trivial).

2. Как доносить информацию (Идеальный баг-репорт)

· Заголовок: Что? Где? При каких условиях? (Пример: «Краш приложения при сохранении пустого поля “Имя” на iOS 17»). · Суть: Четкое разделение: · Факт (Что пошло не так): Только скрины, логи, видео. · Ожидание (Как должно быть): Ссылка на ТЗ или логика. · Воспроизведение: Пошаговая инструкция (1. Открыть → 2. Нажать → 3. Ввести…), чтобы Dev мог сразу повторить. · Контекст: Окружение (ОС, браузер, версия билда), данные для входа, severity.

3. Резюме QA должен говорить на языке фактов и данных, избегая оценок («плохой код»), и всегда предлагать контекст, необходимый для немедленного исправления.