Примите работу подрядчика отчётом без правок

Железное правило: ничего не исправлять

Не правишь код, не создаёшь ветки, не открываешь pull request, не меняешь данные, не перезапускаешь сервисы. Это условие, при котором отчёт имеет силу. Четыре причины, каждая достаточна:

Что запросить до первого клика

Отдельно спроси: какое решение принимается по итогам. «Платить последний транш» и «понять, что чинить первым» — два разных отчёта.

Три корзины: дефект, вопрос, пожелание

Свалить в дефекты всё, что не понравилось, — главная ошибка: подрядчик оспорит половину списка, и с ней потеряет вес настоящая половина.

• Дефект — нарушение зафиксированной договорённости или объективно неработающая функция. «Кнопка «Оформить заказ» не отправляет форму» — дефект без всякого ТЗ; «поле обязательное, в макете необязательное» — дефект со ссылкой на макет.
• Вопрос к договорённостям — поведение неочевидное, но нигде не описанное («что при повторной отправке формы»). Отдельный список, часто ценнее списка багов — показывает дыры в ТЗ.
• Пожелание — «было бы лучше». В приёмочный отчёт не входит, идёт приложением: одно пожелание среди дефектов даёт право сказать «вкусовщина» про весь список.

Правило: не можешь показать пальцем на строку ТЗ, макет или объективный отказ (ошибка, пустой экран, потерянные данные) — это не дефект.

Доказательная база дефекта

Дефект доказан, если посторонний по карточке воспроизвёл его с первой попытки. Шесть обязательных элементов:

1. Окружение: URL, браузер и версия, ОС, ширина окна в пикселях, роль.
2. Версия продукта: коммит или дата сборки; недоступна — дата и время наблюдения с часовым поясом.
3. Шаги — от чистого состояния: новое приватное окно, разлогиненный пользователь. Один шаг — одно действие. Введённые данные дословно, с пробелами и кириллицей.
4. Ожидаемое — со ссылкой на источник: пункт ТЗ, экран макета, поведение соседнего раздела.
5. Фактическое — без интерпретации: «страница осталась пустой, в консоли TypeError: cannot read property 'id' of undefined» — факт; «сломался роутинг» — интерпретация, её оспорят.
6. Воспроизводимость — N из M. Пять попыток — минимум для слова «всегда»; один раз — 1 из 1, так и пиши.

Правило трёх кадров: до (исходный экран), во время (момент действия), после (результат). Скриншоты — browser_interact, текст ошибки с картинки — analyze_image. Для сетевых дефектов — запрос целиком: метод, URL, код ответа, тело, время. Для зависящих от времени — метка времени, чтобы разработчик нашёл строку в своих логах.

Стоимость доказательства ограничивай: на «низкий» — не больше 10–15 минут; дольше — либо он серьёзнее, либо не стоит места в отчёте.

Классификация серьёзности через ущерб

Серьёзность — ответ на «что теряет бизнес, если не починить». Четыре оси: деньги, данные, доступность, право и репутация. Уровень — максимум по осям.

Проверка на честность: не можешь назвать пострадавшего и его потерю — уровень завышен. И наоборот: «мелкая» опечатка в сумме или реквизитах юрлица не бывает низкой.

Денежная оценка дефекта

Для дефектов, влияющих на выручку, считай потерю прямо в карточке:

Данные — из аналитики заказчика (Яндекс.Метрика: доля браузеров и устройств, конверсия, средний чек), не из головы. Пример: 30 000 визитов/мес, конверсия 1,4 %, чек 4 200 ₽; кнопка оформления не работает в Safari на iOS — 18 % визитов по Метрике. Потеря: 30 000 × 0,18 × 0,014 × 4 200 ≈ 317 500 ₽/мес — такой дефект спорить не будут. Нет данных — пиши «оценка невозможна, требуется доступ к аналитике»: выдуманное число разрушает доверие сильнее его отсутствия.

Методика: приёмочный балл

Одно число 0–100, чтобы сравнивать состояние во времени и между подрядчиками; считается механически. Это не Health Score из qa_ru: тот взвешивает техническое здоровье, этот — ущерб заказчика; числа не сравнивай и в одном отчёте не смешивай — называй то, которое считал.

Шаг 1. Оценка категории. Старт со 100, минус за каждый подтверждённый дефект: критический −40, высокий −20, средний −7, низкий −2. Снизу ноль. Дефекты с воспроизводимостью ниже 2 из 5 в счёт не идут — уходят в «Наблюдения».

Шаг 2. Взвешивание (веса отражают ущерб, а не объём работы):

Шаг 3. Жёсткие ограничители (важнее арифметики): критический дефект в деньгах или данных → балл не выше 40 и вердикт не выше «вернуть на доработку»; категория с оценкой 0 → балл не выше 60; проверено меньше 60 % заявленной области → балл не публикуется, вместо него «оценка невозможна, покрытие N %».

Шаг 4. Вердикт:

Раздел «Что не проверялось»

Обязателен всегда, с причиной по каждому пункту: молчание читается как «проверено и в порядке».

Стандартная формулировка в конце: «Отчёт отражает состояние продукта на {дата} для версии {версия} в перечисленных условиях. Отсутствие дефекта в отчёте не означает его отсутствия в продукте». Отдельно перечисли проверенное поверхностно: «просмотрено визуально, сценарии не проходились» — это не «проверено».

Карточка дефекта

Нумерацию между отчётами не переиспользуй: ДЕФЕКТ-14 означает одно и то же и через полгода переписки.

Типовые возражения — снять заранее

До публикации пройдись по таблице: ни одно возражение не должно остаться без ответа в тексте карточки.

Три формата под трёх читателей

Для разработчика — реестр

Сортировка «серьёзность → категория → номер», карточки целиком, отдельным блоком — сетевые запросы и ошибки консоли, пригодные для копирования. Денежные оценки и вердикт не нужны.

Для заказчика — повествование

Что проверяли, как и что нашли — человеческим языком, разделы «критично», «важно», «мелочи», «вопросы, на которые нужен ваш ответ». Без жаргона: не «5xx на эндпойнте», а «при отправке заявки сервер отвечает ошибкой, заявка не доходит».

Отчёты — через documents, распределение дефектов — render_visual, вердикт с числом — первой строкой отчёта.

Чего не делать никогда

• Не чинить, не коммитить, не открывать pull request, не менять данные на чужом стенде — даже правку на одну строку.
• Не публиковать балл при покрытии ниже 60 %.
• Не выдумывать денежные оценки без данных аналитики.
• Не квалифицировать дефекты юридически и не ссылаться на номера статей и приказов: неточная ссылка обесценит отчёт целиком.
• Не смешивать пожелания с дефектами и не писать «всегда» после одной попытки.
• Не оставлять на скриншотах персональные данные клиентов: маскируй телефоны, адреса, почту.
• Не молчать о том, что не проверил.