Традиционный пятничный мастер-класс прошел весело и задорно. За двадцать минут рассмотрели ошибки тестировщиков (они, оказалось, у всех одинаковые), что с ними делать и как избежать. Видосик с архивом происшествий приаттачен.

Расшифровка видео — под ним. Осторожно, многобукаф.

Дисклеймер: используется ненормативная лексика. Потому что так понятней. Уберите детей от экрана!

Две недели назад мы зарелизили новый сайт Сибирикса. За несколько дней до этого в студии проходил локальный апокалипсис. Люди бегали по офису, писали во внутренний чат: «Аааа, срочно, важно!!!», закидывали менеджера пожеланиями и хотелками. И менеджер что-то решал :)

Но попробуй-ка подойти с багом прямо в голову к матерому программисту. В панике прибеги, скажи: «Срочно, важно, давай реши!» Какая реакция возникнет? Психанет. В большинстве случаев.

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

1. Делаем багтрекер (можно на коленке)

Дабы минимизировать вражеское общение, создаем локальный багтрекер. Делаем на коленке или используем Jira, например.

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

2. Не создаем конфликты на ровном месте

Когда пишешь разработчику матом, либо КАПСОМ, либо просто «баг» или даже «косяк» — это воспринимается как личное оскорбление. Это серьезный плевок в душу разработчика.

Пишите простыми, понятными формулировками. Не машите кулаками там, где не должно быть драки.

Что тут плохо? Непонятно.
Ответят вот так:

Когда начинаете диалог, пишите нейтральными словами.

Начнете диалог — вам ответят.

Наши заказчики иногда развернуто отвечают:

Оскорбление, капс, ссылка некликабельная. Это раздражает. Ссылки делайте кликабельными, «Гуглодоки» и последние версии «Экселя» это умеют.

Но разработчику понятней не стало:

3. Используем скриншоты

Некоторые заказчики вставляют скриншот картинкой в «Эксель». Да, старательно вырезают в «Паинте», а потом аттачат файл. Вот вам скриншот, вот написано, где баг. Это ужасно.

Ладно, когда баг один. Если багов много — таблица превращается в нечитабельный фарш. Непонятно, что за баг. Его невозможно найти. Ссылка не работает, или ошибка в тексте.

Возникает желание показать — добавьте скриншот.

4. Приводим к единому формату

У нас есть принятый формат таблички. Он выглядит адекватно:

• в заголовок таблицы добавлено название проекта;
• в названии вкладок записываются даты, когда проводилось тестирование;
• во всех листах — одинаковая шапка с приоритетом, браузером, описанием и скриншотом;
  
• комментарии вынесены в отдельную графу. Тот, кто пишет комментарий — обозначает свое имя.
  

Иногда тестировщики присылают экзотически названные листы «BUGS FINAL BUILD 15 LATEST VERSION BY VASILIY POUPKINE». Так делать не надо. Должно быть понятно, в каком браузере происходит баг и в каком месте. И дальше ссылка на скриншот.

5. Пишем адекватно

Скриншот — инструмент для демонстрации. Им можно проиллюстрировать явление, но не зафиксировать.

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

Такой скриншот неинформативен. Непонятно, в чем проявляется баг. Добавьте конкретики.

Сделайте описание бага на листе.

Скриншот дополнен комментарием, но не информативен.

Когда скриншот один — это еще терпимо. Если их много — баглист превращается в мешанину.

6. Не используем ссылки «См. п. N»

Часто тестировщики пишут «Аналогично строке 14»... Что здесь не так? Менеджер пересортирует документ, скопирует пару строк из одного баглиста в другой... И связь пропадет. Не надо делать такие включения. Каждое описание должно быть в понятном текстовом виде.

7. Делаем понятные описания проблемы

По такому описанию проблема найдена. Но слово «абракадабра» лучше заменить. Проблема-то для юзера. Для разработчика нормально, он же правильно все сделал, загрузил через Битрикс.

Ну да, ссылка есть, все стандартно. Битрикс в этом разделе генерировать понятные урлы не обучен. Разработчик говорит: «норм». А SEO и впечатление от просмотра страдают.

8. Не указываем личные мнения

Частая ошибка — пишем не то, что надо сделать, а личные мнения. Такие комментарии покрасят серым и проигнорят.

Другая ситуация, по сути, примерно такая же. Выписываем комментарий — но непонятно, баг это или фича. Кнопка зеленая! Спасибо, кэп. Она должна быть зеленая? Она сейчас зеленая? Или она при определенных обстоятельствах должна быть зеленой? Это конкретно бесит. Это текст ради текста.

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

9. Расставляем приоритеты

Наши разработчики идут по баглистам в порядке приоритетов:

0 — критические баги, сайт не работает вообще или работает не так, как ожидается;
1 — критичное юзабилити, забытые фичи;
2 — некритичные баги;
3 — некритичное юзабилити;
4 — ошибки в текстах;
8 — хотелки.

Написали «Ссылочку мне сделай красиво». Ок. Баг без приоритета. Разработчик начнет делать вперемешку, если не проигнорит. И будет злиться и посылать в далекое пешее путешествие.

При таком подходе программист исправит баг, и даже не особо перенервничает. Ну ладно, раз просит — сделаю.

10. Не подкидываем посуду

Новый сайт Сибирикса тестировали ежедневно. Каждый день создавался новый лист. Баги отлавливались сразу.

В чем минус постоянной работы над проектом?

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

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

Бывает и такое, что не апнули боевой сервер для теста. Об этом лучше сразу сообщить разработчику до начала тестирования.С критическими вещами, которые не дают проверить систему, лучше по-быстренькому попросить разобраться. Если рядышком сидите. Это сильно обезопасит вас от получения негативной обратной связи, а мир станет чище и добрее ;)