Home

Автор: Ольга Киселева, тренер курса Онлайн-интенсив для начинающих тестировщиков

У тестировщика миллион способов завести баг так, чтобы разработчики на него забили. Учитесь ставить такие задачи, которые будут исправлять.

1. Выберите тип

Разработчики не боги, они не могут делать все и сразу. Им нужно понимать, с чего начинать. Они сортируют задачи по типу — сначала новые функции, потом ошибки, потом все остальное.

Какие бывают типы задач:

• Баг — ошибка в программе.
• Улучшение — все ок, но хотим с перламутровыми пуговицами.
• Новая разработка — такой возможности нет, а очень хочется.

Допустим, заказчик захотел новую возможность, а вы завели ее не как новую возможность, а как баг. Разработчики весь месяц делали другие новые функции, и до вашей не добрались. Заказчик в ярости: вы же обещали... А виноват постановщик задачи — умей выбирать тип!

Осторожнее с ошибками. Разработчик не любит слышать, что в его детище что-то не так. Он будет топать ногами и кричать “Это не баг и исправлять его не надо”.

Финт ушами — ставьте улучшения вместо некритичных ошибок.

Системный архитектор реагирует на появление ошибки

2. Локализуйте проблему

Локализация — это поиск первопричины.

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

Когда мы тестировали систему Дадата, обнаружили, что “Гунько Александр” женского рода. Первая реакция — бегом ставить баг! Хотя нет, постойте...

В чем тут проблема?

Система всех “Гунько” считает женщинами?

Или “Гунько Марина” тоже сменит пол?

А “Иванов Петр” — мужчина?

Младший разработчик локализует свой первый баг

3. Придумайте короткий и емкий заголовок

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

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

Соизмеряйте важность проблемы и название задачи.

Если в заголовке появились слова "Ошибка", "Неправильный", "Некорректный", "Неверно" — перепишите заголовок. Вы заводите задачу с типом "Ошибка" — уже понятно, что что-то работает не так. Объясните проблему: “Можно зарегистрироваться с именем Ктулху”.

Но если вы заводите улучшение, заголовок должен предлагать, а не ставить перед фактом: “Запретить регистрацию с именем Ктулху”

3. Приложите скриншот

Первое, что цепляет взгляд — это картинка.

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

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

На картинке не должно быть ничего лишнего. Если нужна только маленькая часть экрана — прикладывайте ее, а не весь рабочий стол. Если скриншот получается большим, выделите в нем область, на которую надо смотреть, например, нарисуйте стрелочку.

                                       ↓

4. Опишите шаги воспроизведения и результат

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

Шаги — короткие, емкие и последовательные. Разработчик должен выполнить их, а не задумываться над тем, что и в каком порядке ему делать.

Если шаги непонятные, разработчик не станет в них разбираться. Ему это не нужно. он закроет задачу: “не воспроизводится”. Увы, на баг забили!

Все знают, что шаги должны быть короткими и емкими. На практике мои студенты ударяются в 2 крайности — слишком кратко или слишком длинно.

Слишком кратко → когда нужно тратить время, чтобы понять, о чем речь. Студенты думают, что у разработчика уже открыт сайт на нужной странице, поэтому пишут просто “Сделай так!”. Но разработчик может вести сразу несколько проектов и такие шаги ставят в ступор. Где сделай? Что за проект? В каком месте системы этот раздел находится? Где ссылки, в конце то концов??

Слишком длинно → когда поленились локализовать. Бродишь по сайту, отчаявшись найти проблему, и вдруг… ОШИБКА! Первое стремление — скорее, скорее ее завести. Кажется, что все действия крайне важны. Даже если они не имеют реального отношения к проблеме. Ведь так воспроизводится? Заводим!

Как для разработчика выглядят шаги воспроизведения бага

5. Обоснуйте ожидаемый результат

Раз вы ставите баг → вы считаете, что в системе есть проблема. Но почему это проблема? И для кого? Насколько она реальна?

Недостаточно сказать “поле email должно быть 23 символа” — а с чего вы взяли? Вспомните, что такое баг и обоснуйте свои ожидания.

У разработчика и тестировщика разные взгляды на проблемы. То, что мешает тестировщику, разработчик считает нормальным поведением. И если его просто ставить перед фактом: “Это баг, исправляй!”, пощады не ждите. Разработчик не станет бегать за автором с вопросом “А почему это проблема? Объясни, пожалуйста”. Он просто закроет баг.

Опишите сценарий использования, в котором возникает ошибка. Покажите, что в другом похожем месте система ведет себя по-другому (неединообрзно → плохо!). Дайте пруфлинки.

---------------------------------------------------------------------------------------------

Тотальная паранойя — друг тестировщика!

Конечно, даже идеально поставленную задачу не всегда исправят. Но лучше поставить задачу, чем не ставить. Пусть хранится для истории.

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

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

Как-то раз нашла я проблему и пришла к главному разработчику — баг? Он отмахался от меня: "Нет нет, все ок, это не баг. Так и должно работать". А через две недели прибежал к тестировщикам с выпученными глазами и начал кричать "Тестировщики лентяи, такую багу пропустили!!!". Пропущенным багом оказалась… Та самая проблема.

— Погоди, я же тебе ее уже показывала, ты сам сказал, что это не баг.

— Не было такого! Вы лентяи, такую бажину пропустили!

И не докажешь уже, что не индюк, не записано :)

PS — статья написана в помощь студентам моего курса для начинающих тестировщиков.