← вся теориятеория к собесу · Теория тестирования

Тест-документация и баг-репорты

Тест-кейсы и баг-репорты

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

Стержень: репорт стоит ровно столько, сколько в нём воспроизводимости, а severity и priority - две независимые оси, которые постоянно склеивают в одну.

// Формулировки: «что должно быть в баг-репорте?», «чем severity отличается от priority?», «что такое тестовый оракул?».

Кейс и репорт: что делает их рабочими

Тест-кейс устроен просто: предусловия (что должно быть готово до начала), шаги, ожидаемый результат. Главное правило - один кейс проверяет одно. Кейс на 40 шагов упадёт на двенадцатом по постороннему поводу, и вы полдня будете выяснять, что именно сломано. Там, где детализация не нужна - опытному тестировщику на знакомой функции, - берут чек-лист: список того, что проверить, без расписывания каждого клика.

Баг-репорт живёт по тому же принципу, но его качество измеряется одним: воспроизводится ли он у чужого человека на чужой машине. Значит внутри: точные шаги с реальными данными (не «ввёл имя», а ввод, скопированный как есть), фактический результат против ожидаемого, среда и версия сборки, логи, скриншот или запись экрана.

// И правило, которое экономит нервы: один дефект - один тикет. Пять проблем, сваленных в один, чинятся частично: три поправили, тикет закрыли, две потерялись навсегда и всплывут через полгода как новые.

предусловия: состояние системы, которое должно быть готово до первого шага
чек-лист: список проверок без расписывания шагов, для знакомой функции

Severity против priority

Severity - техническая тяжесть последствий: насколько сильно ломается система. Priority - срочность починки для бизнеса: насколько быстро это надо чинить. Кажется, что одно следует из другого. Не следует, и вот два случая, где оси расходятся в противоположные стороны.

Первый: на главной странице опечатка в названии компании. Технически не ломается ничего, severity низкая. Но это видят все посетители и это бьёт по репутации - priority высокая, чинить сегодня. Второй: полный крах функции, которой пользуются двенадцать человек в квартал. Severity высокая, отказ полный, а priority низкая - подождёт пару недель.

// Кто какую ось ставит: severity - тестировщик, по факту поломки, он её видел. Priority - продукт или менеджер, по влиянию на бизнес, потому что это их зона. Склеите оси в одну - и команда починит крах у двенадцати человек раньше опечатки, которую видит вся страна.

severity: техническая тяжесть поломки; ставит тестировщик
priority: срочность починки для бизнеса; ставит продукт

Оракул и как писать про «иногда падает»

Откуда вообще берётся строчка «ожидаемый результат»? Источник знания о том, как должно быть, называют тестовым оракулом. Их несколько: спецификация, поведение предыдущей версии, аналогичный продукт, внутренняя согласованность (на одном экране сумма 1500, на другом 1 500,00 - оракул сработал), наконец здравый смысл. Последний тоже полноценный оракул, но его надо проговорить в репорте явно, иначе разбор превращается в «а где написано, что так нельзя».

Отдельная беда - мигающие дефекты, то есть те, что воспроизводятся не каждый раз. Я замерял тест, который ждёт ответа не дольше 20 миллисекунд, а сервис отвечает за 5-25: 68 падений на 300 прогонов. Если написать «иногда падает», репорт вернут как невоспроизводимый. Если написать «падает 68 раз из 300, ответ приходит за 5-25 миллисекунд при ожидании 20» - это диагноз, по нему сразу видно причину.

// Метрики по дефектам полезны, пока по ним принимается решение. Доля дефектов, вернувшихся после «починки», покажет, что фиксы не доводят до конца. Плотность дефектов по модулям покажет, где копать. А показатель «сколько багов завёл тестировщик» портит и репорты, и людей: плодить мелочь выгоднее, чем найти один дорогой дефект.

тестовый оракул: источник знания о том, каким должен быть результат
частота в репорте: «3 из 10» вместо «иногда» - превращает мигание в диагноз

Как отвечать: «Чем severity отличается от priority?»

Это две независимые характеристики дефекта, и их постоянно склеивают. Severity - техническая тяжесть последствий: насколько сильно баг ломает систему. Приложение падает - высокая, съехал отступ - низкая. Priority - срочность починки с точки зрения бизнеса. Ключевое, что они не выводятся друг из друга, и лучше всего это видно на двух встречных примерах. Опечатка в названии компании на главной технически не ломает ничего, severity низкая, но её видит каждый посетитель и она бьёт по репутации - priority высокая, чинить сегодня. И наоборот: полный крах функции, которой пользуются двенадцать человек в квартал, - severity высокая, отказ полный, а priority низкая, подождёт спринт. Поэтому в репорте я заполняю обе оси отдельно: severity ставлю сам, по факту поломки, я её видел; priority согласую с продуктом, потому что влияние на бизнес - их зона ответственности. Когда оси разведены, очередь фиксов выстраивается по реальному ущербу, а не по тому, насколько громко баг выглядит технически.

Почему это сильный ответ: определения плюс два встречных контрпримера, где оси расходятся в обе стороны, и явно названо, кто какую ось ставит и почему.

На чём валят

−Репорт без точного ввода и среды: у разработчика «не воспроизводится», хотя баг настоящий.
−Склеивать severity и priority - опечатка на главной ждёт за крахом функции для двенадцати человек.
−Пять проблем одним тикетом: три починили, две потерялись навсегда.
−Кейс на 40 шагов - падает на двенадцатом по постороннему поводу, разбор на полдня.
−Писать «иногда падает» вместо «68 раз из 300 при таком-то ожидании» - вернут как невоспроизводимое.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 14, остальные разбираются в тренажёре.

#docs_defects1 / 5
Чем чек-лист отличается от набора тест-кейсов?
A)Чек-лист содержит подробные пошаговые инструкции, а тест-кейс — лишь краткий перечень проверок
B)Чек-лист — краткий список «что проверить»; тест-кейс — детальные шаги и ожидание
C)Это полные синонимы, и разницы в детализации между ними на практике практически нет
D)Чек-лист применяют в автоматизации, а тест-кейсы — в ручном тестировании
показать ответ и разбор
+B)Чек-лист — краткий список «что проверить»; тест-кейс — детальные шаги и ожидание
// разбор: Это два уровня детализации тестовой документации. Чек-лист — компактный перечень пунктов «что должно быть проверено» (например: логин с верными данными, логин с неверным паролем, восстановление пароля), без пошаговых инструкций и часто без явных ожидаемых результатов; он быстр в создании и хорош для опытных тестировщиков и быстрых проверок. Тест-кейс детален: предусловия, точные шаги, данные, ожидаемый результат — он воспроизводим кем угодно и подходит для сложной логики, передачи работы и трассируемости. Выбор — компромисс: чек-листы экономят время и гибки, детальные кейсы дают повторяемость и полноту ценой затрат на поддержку.
#docs_defects2 / 5
Какие поля обязательны в качественном баг-репорте?
A)Достаточно одного заголовка вроде «кнопка не работает» — остальные детали разработчик выяснит сам
B)Обязательны серьёзность и приоритет, а шаги воспроизведения указывать не требуется
C)Заголовок, шаги воспроизведения, ожидаемый и фактический результат, окружение
D)Полный листинг исходного кода модуля, в котором предположительно возникает данная ошибка
показать ответ и разбор
+C)Заголовок, шаги воспроизведения, ожидаемый и фактический результат, окружение
// разбор: Баг-репорт должен позволить разработчику воспроизвести и понять дефект без личного расспроса. Ключевые поля: информативный заголовок (суть кратко), чёткие пронумерованные шаги воспроизведения, ожидаемый результат и фактический результат (в чём именно расхождение), окружение (ОС, браузер/версия, билд, данные), серьёзность и приоритет, а также вложения — скриншоты, видео, логи. Самое важное — воспроизводимость: баг, который нельзя повторить по описанию, часто закрывают как irreproducible. Заголовок «не работает» без шагов и ожидания бесполезен. Хороший репорт экономит циклы переписки и ускоряет отладку.
#docs_defects3 / 5
Чем severity (серьёзность) отличается от priority (приоритет) дефекта?
A)Это одно и то же, просто severity — технический термин, а priority — его бизнес-синоним
B)Severity задаёт срочность исправления, а priority — техническую тяжесть влияния на систему
C)Оба значения совпадают: высокая серьёзность автоматически означает высокий приоритет
D)Severity — техническая тяжесть влияния; priority — бизнес-срочность исправления
показать ответ и разбор
+D)Severity — техническая тяжесть влияния; priority — бизнес-срочность исправления
// разбор: Severity отражает, насколько сильно дефект ломает функциональность технически: от критического (падение системы, потеря данных) до тривиального (косметика). Её обычно ставит тестировщик по факту влияния. Priority отражает, насколько срочно это чинить с точки зрения бизнеса, и определяет очередь исправления; её задаёт менеджмент/владелец продукта с учётом релизных планов. Эти оси независимы, и именно поэтому они разные поля: критичный по severity баг в редкой функции может иметь низкий приоритет, а «мелкая» опечатка в названии компании на главной — высокий приоритет при низкой severity. Путать их — значит неверно планировать очередь исправлений.
#docs_defects4 / 5
Опечатка в названии компании на главной странице сайта: какие severity и priority?
A)Низкая severity, высокий priority: не ломает функции, но заметно и срочно
B)Высокая severity и высокий priority: видимый дефект на главной странице критичен
C)Высокая severity и низкий priority, так как это всего лишь текст, а не логика приложения
D)Низкая severity и низкий priority: раз ничего не ломается, чинить такую мелочь можно когда угодно
показать ответ и разбор
+A)Низкая severity, высокий priority: не ломает функции, но заметно и срочно
// разбор: Опечатка в названии бренда на главной ничего не ломает технически — система работает, данные целы, поэтому severity низкая (косметика). Но её видит каждый посетитель, она бьёт по репутации и доверию, поэтому бизнес хочет исправить немедленно — priority высокий. Это хрестоматийный пример того, что оси независимы. Зеркальный случай: падение системы при экзотической комбинации настроек, которой пользуется один клиент раз в год, — severity критическая (система падает), но priority низкий (задевает почти никого, можно отложить). Понимание этой независимости позволяет тестировщику корректно выставлять оба поля, а не копировать одно в другое.
#docs_defects5 / 5
Как выглядит типичный жизненный цикл дефекта (bug life cycle)?
A)Дефект проходит один статус — «закрыт» — сразу после его первичной регистрации
B)New → Assigned → Fixed → Retest → Closed; при провале проверки — Reopened
C)New → Closed → Fixed → Assigned: сначала дефект закрывают, а затем назначают на исправление
D)Жизненный цикл дефекта совпадает с фазами STLC всего процесса тестирования
показать ответ и разбор
+B)New → Assigned → Fixed → Retest → Closed; при провале проверки — Reopened
// разбор: Дефект проходит через статусы, отражающие его состояние в процессе. Типичный путь: New (заведён тестировщиком) → Assigned (назначен разработчику) → Open/In Progress (чинится) → Fixed (разработчик заявил об исправлении) → Retest (тестировщик перепроверяет по шагам) → Closed (подтверждено, что устранён). Если при retest дефект всё ещё воспроизводится или всплывает снова позже, его переводят в Reopened и цикл повторяется. Есть и «тупиковые» статусы: Rejected (не дефект), Duplicate (уже заведён), Deferred (отложен), Not a bug. Единый понятный статусный поток нужен, чтобы вся команда одинаково понимала, на какой стадии находится каждый баг.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.

Открыть тренажёр Вся тема: Теория тестирования