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

Когда я только начинал свою карьеру, то совершал достаточно много ошибок при описании дефекта. Даже тот факт, что у меня были инструкции под рукой, мне не помогал. Одно дело читать в теории и совсем другое применять все это на практике. За 10 лет работы у меня накопилось достаточно знаний о том, какие частые ошибки совершает новичок при описании дефектов.

Качественное описание вместо количественного

«Ошибка повторяется редко»

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

Давайте рассмотрим на примере. Предположим, я нашел падение мобильного приложения, но оно повторяется редко. Я оформил ошибку и отправил программистам. Они посмотрели, что падение повторяется редко и решили его не править, т.к. времени на исправление было очень мало. После того как приложение вышло в релиз к пользователям, в тех. поддержку посыпались жалобы, что программа постоянно вылетает.

Что же произошло?
Оказывается, что для меня редко — это 3 раза из 10. Т.е. из 10 пользователей только у 3-х будет проблема. Вроде бы не очень много? Но если увеличить цифры до 1000 пользователей, то получим 300 падений приложения. А это уже совсем другое дело. Зная это, разработчик мог заранее принять меры к исправлению проблемы. Но он не знал о цифрах и подумал, что “редко” это всего лишь в одном случае из 100.

Поэтому старайтесь вместо обобщенных понятий использовать конкретные цифры.

Общий заголовок

«Ошибка на главной странице»

Довольно частая проблема у начинающих тестировщиков. Обычно, разработчики в первую очередь видят только список багов. И чем подробней заголовок, тем проще ему будет ориентироваться в них. Также важно не делать название слишком длинным, это затрудняет чтение. Должно быть среднее между двумя крайностями.

Для качественного заголовка можно также использовать принцип «Что? Где? Когда?». То есть заголовок должен отвечать на вопросы: Что произошло? Где произошло? При каких условиях или когда?

Эмоции в описании

«Когда я нажимаю на эту кнопку, то вообще ничего не работает!»

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

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

Объемное и неструктурное описание ошибки

«Я сначала попробовал сделать вот так, но у меня не получилось, потом нажал на эту кнопку и появился баг. Вроде бы такого не должно быть, потому что в ТЗ написано по-другому. Еще я заметил, что если после ошибки я закрыл приложение, то она больше не повторяется, хотя я пробовал много раз»

Сложно читается? Мне точно да.

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

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

Баг-репорты часто возвращаются к вам с уточняющими вопросами

Последний признак в моем топе. Если команда разработки часто приходит к вам и просит объяснить, что написано в баг-репорте или задает дополнительные вопросы по шагам воспроизведения, значит у вас проблемы с оформлением дефектов.

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

________________________________
Конечно, это не исчерпывающий список. Но даже исправление этих типичных ошибок значительно улучшит качество работы.
________________________________

На этом цикл подошел к концу. Напомню, что предыдущие статьи можно почитать тут:
Назначение отчета https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-naznachenie/
Шаблон отчета об ошибке https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-shablon-otcheta-ob-oshibke/
Приоритет и Серьезность https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-prioritet-i-sereznost/