По ту сторону баг-репорта

В нашем блоге мы уже писали о том, как правильно составлять баг-репорты. Это должен уметь каждый тестировщик. Таинства написания баг-репорта передаются новичкам и стажёрам из уст в уста и в документальном виде. Но иногда с виду стройный и составленный по всем правилам баг-репорт оказывается совершенно нечитабельным для разработчиков и менеджеров проектов, то есть для тех, кому он адресован. В этой статье собраны советы «с той стороны» — стороны разработчика, они помогут сделать баг-репорты понятными команде, обязанной эти баги фиксить (и, конечно, поставлять новые).

Без лишних слов

Для начала откроем страшную тайну:

Разработчики не читают длинные шаги воспроизведения и не смотрят видео с повторением бага. Точнее, читают и смотрят только тогда, когда они не смогли ничего понять из заголовка и скриншота.

Если выстроить составляющие баг-репорта в порядке убывания объёма информации, которую эти части должны содержать, то получится следующее:

• заголовок
• скриншот
• краткое описание
• STR
• видео

 

По опросам, до 90% сути бага разработчики могут понять из заголовка, составленного по принципу «Где? Что? Когда?», и статической картинки или короткой гифки, фиксирующей ошибку. Причина проста: программист лучше тестировщика знает функционал, который делал он или его коллеги. Поняв, где искать ошибку, он будет сам пробовать повторить её, не вчитываясь в STR.

Если вы не знаете, писать ли полный STR, попробуйте соразмерить важность бага с объёмом описания. В репорте о том, что на определенной странице сайта или приложения появляется ошибка 404, достаточно написать конкретный заголовок (например, «Ошибка 404 на странице “Контакты”), по возможности дать ссылку на эту страницу и «заскринить» экран с ошибкой. Для сложных багов, которые повторяются только по шагам, безусловно, нужны STR и видео.

Разговор на одном языке

Тестировщики, менеджеры проекта и разработчики делают общее дело и должны стараться понимать друг друга, при любой возможности улучшать коммуникацию. Важно пользоваться единой терминологией: как общетехнической, так и специфической по проекту. Если вы услышали или прочитали в старых задачах, что в команде принято называть слайдер картинок на главной странице сайта «телевизором», «окна» – «модалками» или «поп-апами», а тестовую и продакшн-версию сайта – «девом» и «продом», смело забирайте эти термины в свой лексикон. Так ваши репорты будут легче понимать, а вы быстрее вольётесь в команду.

Будьте щедрыми

Одна из ключевых функций баг-репорта, помимо собственно сообщения об ошибке, – показать, как ошибку повторить. Особенно это важно для трудных в воспроизведении и «плавающих» багов. Если в интернет-магазине не добавляются в «корзину» определенные товары, вставьте в описание бага ссылки на примеры таких товаров.

Если у вас есть тестовый аккаунт, на котором баг железно повторяется, – не пожалейте дать к нему доступ. У вас всё равно рано или поздно его попросят, но вы сэкономите время на перекидывание бага обратно на вас со статусом «Не воспроизводится» и резонным «УМВР, ЧЯДНТ?».

«И в чём ошибка?»

Извечный вопрос тестировщиков «Баг или фича?» иногда волнует и разработчиков. Когда новый тестировщик находит нелогичное поведение в давно сделанном функционале, вся команда может зависнуть в раздумье, что не так и где ошибка. Может, вы приняли фичу за баг, а может, лишь ваш не замыленный глаз заметил неправильное поведение функционала. Если вы чётко знаете, что не так и как должно быть – напишите об этом. Если не знаете, но догадываетесь, – напишите Suggestion и предложите свой вариант исправления неточности. Это отличная возможность внести в проект что-то своё. Лиды проекта оценят ваш потенциал, и возможно, согласятся с вашим предложением.

Зёрна от плевел

Бывает, что баг-репорт большой и никак не хочет разделяться на составляющие. А то и вовсе – на вас повесили задачу с описанием функционала, который нужно проверить. Разработчик скажет вам спасибо, если вы, фиксируя статус проверки, не свалите всё в одну кучу, а разделите пофикшенное и непофикшенное, сделанное и не сделанное.

Каждая команда разработки может дополнять этот список пожеланий разными пунктами в зависимости от того, как здесь принято писать и читать баг-репорты. Руководствуйтесь здравым смыслом, пытайтесь смотреть на свои репорты глазами человека, видящего их первый раз, и вы поймёте, в какую сторону нужно двигаться.

Текст: Ксения Монаенкова, PM, Bytex