Четверг, шесть вечера. Менеджер спрашивает в чате: «Ну что, выпускаем?» — и вы отвечаете как чувствуете: «Да вроде нормально, пара мелких багов осталась». В понедельник выясняется, что часть покупателей не может заплатить бонусами, а оплату картой не проверял никто: шлюз на стенде не отвечал со вторника.
Менеджер услышал ощущение одного человека, а решать ему: нужна картина — что проверено, что нет и почему, чем рискуем, если выпустим сегодня. Записанная картина и называется отчётом о результатах тестирования.
Сверху — прогон, свёрнутый в одно число: двадцать проверок, две красные, «90 % пройдено». По такой строке выпускают. Снизу тот же прогон, разложенный по важности: обе упавшие проверки оказались в оплате — это половина всего, что про деньги. Процент не соврал, он просто сложил проверку оплаты и проверку иконки с одинаковым весом.
Кто читает отчёт и что в нём обязательноспросят на собеседовании
Читателей четверо. Менеджер решает «выпускаем или нет»: что сломается у покупателей и насколько страшно. Разработчику нужно, что упало, на какой сборке и что чинить первым. Другой тестировщик или вы через месяц — что уже проверено. Поддержка — что отвечать на звонок в понедельник. Первый из них читает один абзац и дальше не идёт, поэтому вывод ставят первым.
Отчётом бывает и страница в задаче, и десять строк в чате, а вопросов в нём везде пять: к чему относится (сборка, стенд, период, кто проверял), что проверено, что не проверено и почему, какие дефекты открыты и насколько тяжёлые, риски и вывод. Первые два портят чаще всего. Без сборки «18 пройдено, 2 упало» — числа неизвестно про что, и это же поле гасит спор «а у меня всё работает». А «что проверено» — не «провели тестирование», а какие наборы прогнали и что из них руками, а что автотестами: доверие к отметкам разное.
Абзац про непроверенное — самый ценный
Про проверенное читатель узнаёт из текста, про непроверенное — ниоткуда, и молчание читает как «проверено». Так в четверг вечером и теряется оплата картой.
Причин три, и решения по ним разные. Не успели — можно дать день, можно выпустить и проверить после. Не было чем — данных нет, шлюз не отвечает; лишний день не поможет, нужна чужая помощь, и такая строка должна попасть к менеджеру как можно раньше. Сознательно не брали — область была за границей объёма ещё в тест-плане; хватит ссылки, но без неё через месяц это выглядит пропуском.
Формулируют тройкой — что, почему, чем обернётся: «Оплату картой не проверяли: шлюз на стенде не отвечает со вторника. Если там сломано, увидит каждый покупатель на шаге оплаты». Ненаписанное непроверенное через неделю становится вашей виной, написанное — общим решением команды.
Дефекты: не число, а список с весом
«Открыто 12 дефектов» не значит ничего: двенадцать съехавших иконок и двенадцать поломок оплаты — разные выпуски при одном числе. Вес задают severity и priority, поэтому в отчёт идёт разбивка по важности, а каждая группа разворачивается на три состояния: что блокирует выпуск, что в работе и уже оценено, с чем выпускаем сознательно и до какого срока. Без срока через полгода не отличить «терпели специально» от «забыли». И каждый дефект — номер записи в трекере, а не пересказ своими словами: такой не найдут и не проверят.
Вывод, за который не стыдно
Вывод читают все, а пишут последним и уставшими. Испорченный — это ощущение («вроде работает»), перестраховка без причины, решение за менеджера («выпуск откладываем») или непроверяемое «качество приемлемое». Полезный собран из состояния, условия и названного риска.
Сьют «Оплата бонусами» пройден на сборке 4.19: 18 проверок из 20, блокирующих нет. Готово к выпуску с двумя оговорками: оплата картой не проверялась (шлюз на стенде не отвечает со вторника) и при нулевом балансе бонусов кнопка списания остаётся активной (BR-118, некритично, в работе). Риск: если в оплате картой сломано, это увидят все покупатели на последнем шаге, откат сборки — около часа.
Состояние опирается на список и сборку, поэтому проверяется за минуту, а риск описан через того, кто его увидит. Вывод «выпускать рано» строится так же: что падает, как часто, во что разработчик оценил починку и сколько займёт повторный прогон.
Метрики: какие бывают и чем их ломаютспросят на собеседовании
«Качество» одним числом не меряется: каждая метрика отвечает на один узкий вопрос и полезна, пока этот вопрос помнят.
- Прохождение — готова ли сборка. Ломает смешение статусов: «заблокировано» (выполнить не удалось) — это не «не пройдено».
- Выполнение — далеко ли продвинулись. Без него соседняя врёт: 100 % прохождения при 40 % выполнения — это начало пути.
- Покрытие требований — есть ли области, куда никто не смотрел. Поверхностная проверка даёт те же сто процентов, что десять придирчивых.
- Плотность дефектов (defect density) — где беда концентрируется: дефекты на размер области (экран, модуль, тысяча строк кода), иначе большая часть всегда выглядит хуже. У переписанной на прошлой неделе их больше, а где не искали — всегда мало.
- Найдено после выпуска — она же утечка дефектов (defect leakage): сколько прошло мимо нас к покупателям; честна тем, что считает её не команда. Пару «до и после» сворачивают в эффективность обнаружения (DRE) — долю пойманных до выпуска от всех известных: девять из десяти — 90 %.
- Время жизни дефекта — чинят ли находки. Медиана, а не среднее, и отдельно по важности: критические за три дня, обычные за полгода — это «обычные не чиним вообще».
Ломает метрики превращение числа в оценку человека — это закон Гудхарта: измерение, ставшее целью, перестаёт быть измерением: улучшать число быстрее, чем то, что оно измеряло. Считаете найденные дефекты работой тестировщика — дефект дробится на пять, в трекер идёт косметика; добавьте оценку разработчика по пропущенным — и двое начнут воевать. Так же ломает круглое число целью: «100 % покрытия» даёт кейсы на каждую строку требования, «ноль открытых дефектов» — незаведённую мелочь.
Почему проценты без контекста врутспросят на собеседовании
Процент короткий, и короткость выбрасывает ровно то, что нужно для решения. Неизвестный знаменатель: «пройдено 90 %» — из двадцати проверок или из двухсот и откуда взялся сам список; о том, чего в списке нет, процент молчит. Отсутствие веса — случай с картинки; лечится строкой рядом, что именно попало в оставшиеся десять процентов. Отсутствие порога и динамики: «покрытие 71 %» — хорошо это или плохо, ответа нет, пока не сказано «выросло с 63 % при договорённом минимуме 60 %».
Сводка каждый день и отчёт на выпуск
Стенд лёг во вторник, данных не завезли в среду, а видно это в четверг вечером, когда делать уже нечего. Поэтому кроме отчёта на выпуск пишут ежедневную сводку — ту же летучку, только строками и с числами.
Сборка 4.19: прогнал 12 проверок из сьюта оплаты — 10 пройдено, 2 упали (BR-118, BR-121). Мешает: шлюз на стенде не отвечает со вторника, оплата картой стоит.
Ценность в третьей строке — препятствии: названное во вторник, оно решается в среду, а не всплывает в выпуске. Отчёт на выпуск отвечает не на «как идут дела», а на «выпускаем или нет», и живёт в задаче на выпуск или в системе тест-менеджмента, а не в чате, где утонет за два дня; если сводки писались, он собирается за двадцать минут. Получасовой разбор после выпуска даёт числа для утечки и DRE.
Коротко
- Читателя четыре — менеджер, разработчик, другой тестировщик, поддержка; первый читает один абзац, поэтому вывод стоит первым.
- Обязательных частей пять: к чему относится, что проверено, что не проверено и почему, дефекты с весом, риски и вывод.
- Молчание читают как «проверено»: непроверенное пишут с причиной — не успели, не было чем, не брали сознательно.
- Дефекты показывают разбивкой по важности и тремя состояниями: что блокирует, что в работе, с чем выпускаем сознательно и до какого срока.
- Хороший вывод — состояние, условие и названный риск, а не ощущение «вроде работает».
- Метрика честна, пока по ней никого не оценивают, и значит что-то лишь с порогом и динамикой; отраслевые имена трёх из них — плотность дефектов, утечка дефектов и DRE.
Что почитать дальше
- Тест-план и тест-сьюты — работа с другого конца: отчёт сверяется с ним, включая список «что не проверяем».
- Что такое баг: severity и priority — откуда берётся вес дефекта, без которого разбивка не строится.
- Жизненный цикл бага и трекеры (Jira) — статусы и сроки, из которых считается время жизни дефекта.
- Тест-менеджмент: TestRail, Qase, Zephyr — откуда берутся числа по прогонам.