25 января 2022 29086
В процессе обучения людей, которые только начинают свой путь в профессии QA, я регулярно сталкиваюсь с тем, что многие допускают однотипные ошибки. Мы разобрали некоторые из них и дали рекомендации, как их избежать.
В процессе обучения людей, которые только начинают свой путь в профессии QA, я регулярно сталкиваюсь с тем, что многие допускают однотипные ошибки.
Хочу разобрать некоторые из них и дать рекомендации, как их избежать.

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

1. Неинформативные названия дефектов

О том, как следует и как не следует писать заголовки дефектов, написано уже немало, тем не менее начинающие продолжают наступать на те же грабли.
Популярная рекомендация заключается в том, что заголовок дефекта должен отвечать на три вопроса, совпадающих с названием известной интеллектуальной игры: "Что? Где? Когда?". Совершенно верная рекомендация, почему же возникают сложности в ее применении?

Итак, первое, что следует понимать о заголовке дефекта: он должен описывать суть проблемы. Чаще всего при помощи предложения, построенного по правилам английского, русского (или другого вашего рабочего) языка. Вспомним грамматику. Что такое предложение?

"Предложение — это единица языка, которая представляет собой грамматически организованное соединение слов, обладающее смысловой законченностью."

В целом краткое описание (summary) дефекта должно отвечать на вопрос: "Что не так?" или, другими словами, "А проблема-то в чем?". В самом названии должно содержаться достаточно информации, чтобы можно было составить представление об этом, прочитав только заголовок. Именно для того, чтобы это было понятно хотя бы приблизительно, как раз и необходимо в названии ответить на эти три подвопроса:
  • "Что?" - как минимум должно быть описано то самое поведение программы, которое мы считаем некорректным, несоответствующим требованиям/стандартам/ожиданиям. Грубо говоря, это симптом.
  • "Где?" - в какой части продукта или системы (в каком модуле, на какой странице, с какой фичей)? Назовем это локацией.
  • "Когда?" - то есть при каких условиях воспроизводится дефект. Это триггер.
Рассмотрим некоторые примеры названий дефектов с точки зрения того, дают ли они нам представление о сущности проблемы.

«Incorrect Site Search».
О чем нам это говорит? Можно понять только то, что дефект связан с определенным функционалом, а именно с поиском по сайту. Это ответ на вопрос "Где?". Но что именно не так с поиском? В чем заключается некорректное поведение? Загадка. При каких условиях воспроизводится дефект? Тоже загадка.

Другое summary того же бага: "The result of the action of the empty site search".
Уже теплее... Можно понять, с каким функционалом связан дефект и даже каковы условия его воспроизведения. Но о том, что именно происходит не так - ни слова. "Просто the result" - какой-то результат, без всякой конкретики... А ведь это самое вкусное!

Чтобы понять, в чем проблема, нужно прочитать описание полностью, да еще и попробовать воспроизвести. При пустом поисковом запросе перед списком товаров появляется секция с названиями категорий, и в ней одна картинка слишком большая, что нарушает UI. Кратко в summary это можно описать так:
«After empty search request too large image is shown in “category-view” div».

К этому багу нужно приложить скриншот, конечно.

И вот еще один пример:
"comment".
Да, даже и так бывает... Одно слово, намекающее на область функционала.

Вот так было бы понятнее:
"Fatal error:463 on attempt to post review at product description page".

"broken layout".
Здесь описан симптом, некое некорректное поведение, так что такое описание можно считать ответом (хотя и очень приблизительным) на вопрос "Что (происходит)?". Но где именно это происходит? На какой-то конкретной странице? На любой странице? Непонятно. А что надо сделать, чтобы "верстка поползла"? Ни одного намека.

Правильное краткое описание этого же бага:
“On 150% zoom images at all pages are superimposed”.

И еще пример:
"Регистрация с невалидным адресом электронной почты".

Возможно, название подошло бы для тест-кейса. Понятно, с какой фичей связан дефект (регистрация), известен и триггер - "невалидный эмэйл" (конечно, важно уточнить в подробном описании: "невалидный" - это какой?). Но баг-то в чем?

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


Несколько подсказок, как написать хорошее summary для дефекта

Коротко, но не слишком.
Не забываем, что summary - это все-таки краткое описание, так что писать небольшое эссе на тему в этом поле тоже не стоит. В большинстве случаев вам хватит примерно 7-10 слов (не считая предлогов). Но не стоит вдаваться в другую крайность - 1-3 словами вы не сможете описать ситуацию достаточно ясно.


Избавляйтесь от слов-паразитов , не лейте воду.
Вот пример: "The opening of each new image when viewed on a new tab" .
Многабукаф, а в итоге описан только симптом, и то невнятно.

А суть здесь в том, что каждая картинка при клике на нее открывается в новой вкладке, что, разумеется, неудобно и не соответствует разумным ожиданиям пользователя. Это можно сказать короче и точнее: "On click each image opens in a new tab".
Еще бы уточнить, в каком разделе сайта это происходит (точно не во всех), и было бы вообще отлично.

Еще пример:
"На сайте зайдя в раздел покупок, выдаетcя ошибка при попытке оставить отзыв".
«Подъезжая к сией станции... у меня слетела шляпа». Не умея использовать деепричастные обороты, не стоит этого делать. И вообще лучше избегать громоздких конструкций.

"На сайте" - просто ни о чем. Все дефекты, которые заводят в этом проекте, касаются именно этого сайта, так зачем повторять это в названии дефекта?
Сокращаем:
"Ошибка при попытке оставить отзыв в разделе покупок" - кстати, какая? Неплохо бы обозначить ее хоть как-то - класс, код... Полный текст сообщения об ошибке, конечно, приводить в summary бага необязательно.

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

2. Отсутствие ожидаемых результатов

Когда тестировщик заносит дефект, конечно, у него/нее обычно есть какое-то представление о том, как должно быть правильно. Но вот загвоздка - разработчики, как и все остальные люди, не обладают телепатией! И если ожидаемые результаты не описаны явно, то всегда есть вероятность, что возникнет непонимание.
Кроме того, есть и другой риск. Разработчик может сделать собственные выводы о том, как же должно быть правильно, затем "исправить" и отправить на верификацию. Тут начнутся споры: "Исправлено!" - "Не исправлено!" - "Но вот же, здесь поменяли!" - "Так вообще не это было нужно!". В итоге - потрачено время, силы, нервы нескольких людей...
Гораздо проще сразу объяснить, какого результата вы ожидаете. Даже если кажется, что это очевидно и всем понятно и так. Один из законов Мэрфи гласит: "Всё, что может быть понято неправильно, будет понято неправильно." Особенно начинающим тестировщикам советую ввести это в привычку: всегда прописывать ожидаемые результаты явно. (Еще лучше, если вы можете подкрепить это ссылкой на конкретное требование.)


3. Невнятные шаги воспроизведения

Как бы банально это ни звучало, шаги лучше описывать пошагово. Одна строчка - один шаг. Можно нумеровать, можно не нумеровать, это по желанию. Но не стоит писать одним длинным абзацем, нагромождая when, while, which, then и тому подобное. Глядя на такое длинное и сложное предложение, воспроизвести дефект очень сложно. Даже простую ситуацию можно запутать, описав ее, например, так:
"When purchasing products, when you press a button to buy, pop-up window, which when pressed to continue shopping, throws on the orders page"
Эту ситуацию можно было бы описать так:
“Continue shopping” button redirects to “Orders” page”
Разумеется, эта кнопка не должна перекидывать на страницу заказа, покупатель должен оставаться там же, где и был, чтобы, собственно, продолжать покупки. Эти детали уже можно описать в Description.

4. Скриншот вместо фактического результата

Добавлять скриншоты к дефектам, особенно описывающим проблемы пользовательского интерфейса, конечно, очень полезно. Но! Скриншот не заменяет внятного текстового описания.
"Фактический результат: "Запрос не прошел валидацию (см. скриншот)"

Вот так не стоит делать. Исходя из своего опыта, точно могу сказать, что ситуации, когда фактический результат – что-то неописуемое словами, крайне редка. Да, случались в моей практике и такие баги, что приходилось снимать видео, чтобы нормально проиллюстрировать, что происходит. Но это было буквально пару раз за 10 лет. Практически всегда можно объяснить ситуацию человеческим языком. Если с этим возникают сложности, то, возможно, вы не до конца понимаете происходящее. Скриншот – источник дополнительной информации.

Между прочим, в этом случае скриншот был по каким-то причинам утрачен, и разобраться, что за баг уже просто нереально.

Кстати, иногда и сам скриншот нуждается в доработке, особенно когда интерфейс сложный. Бывает, приходится долго всматриваться в скриншот, чтобы понять, а где же баг. Нарисуйте стрелку, обведите кружочком или подчеркните, чтобы было сразу очевидно, в каком месте проявляется дефект. Иногда стоит просто отрезать лишнее и оставить только то, что полезно для иллюстрации бага.

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

Устраняем ошибки, повышая свою квалификацию на курсах.

Продолжение следует...

Курсы по тестированию ПО.

Последние статьи в блоге

Сквозная логика: от бизнес-процесса к реализации без потерь

Главный принцип работы с проектной документацией — поддерживать её связность и актуальность. Любая, даже самая детальная схема (BPMN, Use Case, C4), мгновенно теряет ценность, если она конфликтует с другой. Узнаёте? Сначала все силы бросают на «личный кабинет», но после пары спринтов главным внезапно становятся «возвраты». В результате возникает опасный разрыв: цели проекта, реализуемый функционал и схемы, которые должны их описывать, живут своей жизнью. Документация превращается в «мёртвые зоны», которые больше не отражают реальность.

29 августа 2025

Заказная разработка ПО в IBS: безопасная разработка и доставка

В этой статье начальник отдела DevOps компании IBS Артур Галеев расскажет об опыте внедрения принципов безопасной разработки, используемых инструментах и нормативных актах, на которые стоит опираться.

Новости
26 августа 2025

Сертификация ИТ-специалистов: точная оценка ваших компетенций

В ИТ-мире важно не просто обладать знаниями, но и четко понимать свой реальный уровень владения теми или иными навыками.

Новости
22 августа 2025

Группа компаний IBS запускает национальную сертификацию для бизнес-аналитиков

Центр сертификации IBS запускает новую систему оценки квалификации бизнес-аналитиков, которая сочетает международные стандарты c особенностями российского рынка. Программа ориентирована на теоретическую базу и прикладные навыки, необходимые в работе бизнес-аналитика в современных ИТ- и цифровых проектах.

Жизнь компании
20 августа 2025

От разработчика к тренеру: как превратить экспертизу в стабильный доход

Часто к преподаванию переходят после достижения «карьерного потолка»: на уровне сеньора процессы отлажены, и новые вызовы исчезают. Однако вместо того чтобы долго преподавать за символическую плату, можно сосредоточиться на создании системного заработка. Разберём реальные способы: от коучинга до запуска курсов.

Новости
13 августа 2025

Установка и настройка брокера сообщений Kafka на Windows

Цель задания: научиться устанавливать и настраивать Apache Kafka на операционной системе Windows, а также выполнять базовые операции с топиками и сообщениями.

21 июля 2025

Почему Python? Полный разбор Python vs Java в ML

«Когда 9 из 10 курсов по машинному обучению используют Python — это не случайность. Это результат десятилетия эволюции инструментов, сообщества и образовательной экосистемы».

21 июля 2025

Что должен знать и уметь архитектор ПО в 2025 году

Представьте профессию, в которой нужно одновременно мыслить как инженер, говорить как консультант и чувствовать бизнес как продакт. Архитектор ПО — это не просто старший разработчик с модным названием должности, а человек, который соединяет технологии, людей и цели в устойчивую, масштабируемую систему. Но какими навыками он должен владеть сегодня, чтобы быть действительно востребованным?

21 июля 2025

Памятка по документированию архитектурных решений

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

Новости
18 июля 2025

Летняя акция: учитесь онлайн с выгодой, не выходя из отпуска! До конца августа второй курс со скидкой 50%

Проведите лето с пользой для карьеры – второй курс со скидкой 50%!

09 июля 2025

5 курсов июля со скидкой 30%

Друзья, у нас остались последние места на курсах, которые стартуют в июле. Сейчас есть возможность записаться на обучение со скидкой 30%!

Новости
04 июля 2025

Карьерный трек аналитика: от базы к экспертизе

Системные и бизнес-аналитики аналитики играют ключевую роль в digital-развитии продуктов. Эти специалисты выступают связующим звеном между бизнес-задачами и техническими решениями, обеспечивая эффективную коммуникацию между заинтересованными сторонами. Рассмотрим карьерные пути в аналитике, актуальные требования рынка и перспективы профессионального роста.

27 июня 2025

Почему именно сейчас стоит учиться на бизнес-аналитика уровня Middle. «Руководство BABOK» в подарок участникам программы!

Вы в ИТ, вам за 30. Вроде бы всё хорошо — есть работа, скиллы, стабильность. Но в воздухе — тревожность. Проекты замораживаются. Бизнес урезает бюджеты. От ИТ ждут не просто задач, а конкретного влияния на прибыль.

25 июня 2025

Уничтожит ли ИИ-генератор кода профессию разработчика?

С появлением ИИ-инструментов, а также в связи недавним анонсом Canva Code, который генерирует код за пару кликов, многие задумались: не станут ли такие инструмент угрозой для разработчиков? Давайте разберемся, есть ли здесь реальные риски, или это все же преувеличения.

23 июня 2025

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

Рассказываем о продвинутой альтернативе привычного резюме для консультантов 1C и других специалистов с проектной занятостью.

Новости
19 июня 2025

Выбор карьеры: Менеджер бизнес-процессов или Бизнес-аналитик уровня Middle?

В мире цифровой трансформации пути развития аналитиков и менеджеров проектов все чаще расходятся: кому-то ближе работа с требованиями и API, а кому-то — выстраивание системной эффективности на уровне всей компании. Какой путь выбрать лично вам?

Новости
18 июня 2025

В Учебном центре IBS планируется запуск курсов по продуктам TData

Читайте о стратегическом соглашении TData и IBS и наших новых курсах

11 июня 2025

Компетенции бизнес-аналитиков: Junior и Middle в сравнении

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

Новости
05 июня 2025

Лимит на сбои. Как понять, что система перегружена, а не просто плохо сделана?

Оценить производительность системы непросто, а контролировать еще сложнее. Как сделать так, чтобы внедряемая или уже эксплуатируемая система справлялась с нагрузками? Можно ли в этом вопросе полностью положиться на разработчиков ПО или вендоров? И кто в итоге будет отвечать за все простои системы? Рассказывает Николай Марченко, директор отделения нагрузочного тестирования компании IBS. Начать следует с того, что разбираться с последствиями возможных сбоев в любом случае придется тем, кто работает непосредственно с системой. Поэтому о вопросах производительности лучше задуматься еще на этапе внедрения.

Новости
03 июня 2025

Кто такой аналитик 1С?

Аналитик 1С — это специалист, который занимается оптимизацией бизнес-процессов с использованием программного обеспечения 1С. Его задача — анализировать существующие процессы, выявлять недостатки и разрабатывать решения для повышения эффективности. Аналитик переводит бизнес-требования в технические задания для разработчиков, становясь мостом между пользователями и ИТ-отделом. Эта роль требует как технических знаний, так и навыков коммуникации, что позволяет вносить значительный вклад в развитие компании и улучшение её конкурентоспособности.

Новости
28 мая 2025

Не нашли, что искали? — Просто напишите, и мы поможем

Корпоративное обучение Оценка персонала Сертификация О нас Стань тренером Блог
Пользователь только что записался на курс ""
Спасибо!
Форма отправлена успешно.