Распространенные ошибки начинающих тестировщиков

В процессе обучения людей, которые только начинают свой путь в профессии 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 лет. Практически всегда можно объяснить ситуацию человеческим языком. Если с этим возникают сложности, то, возможно, вы не до конца понимаете происходящее. Скриншот – источник дополнительной информации.

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

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

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

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

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

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