Всем привет. Меня зовут Дарья и я – специалист по контролю качества программных продуктов компании «Ренессанс страхование», а проще говоря – тестировщик. «Ренессанс страхование» — не первое мое место работы тестировщиком. Я расскажу о том, как не надо делать, то есть на подробно, на примерах, распишу наиболее частые ошибки при заведении бага.

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

Итак первый баг - «Вот в эту систему захожу и нажимаю отключить»

Бывает так, что нам, тестировщикам, кажется очевидным и простым – для других сотрудников не так, ведь они одновременно работают с различными системами. Им из-за неудовлетворительного качества бага придется потратить время на уточнение, о чем вообще идет речь (какой продукт, какая среда, какая система и тд).

• «При кодировке UTF 8 русские слова переносятся кракозябрами»

Единственное, что хочется сказать после прочитанного – кракозябра вполне может быть милой:). Да, в настоящее время IT-специалисты, понимают, что хотел сказать автор данного бага. Но тут уже возникает вопрос отношения к коллегам и работе. Неужели нельзя затратить чуть больше времени и вместо «панибратских» выражений технически грамотно описать проблему?

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

• подрыв репутации конкретного тестировщика и всех тестировщиков компании;

• занижение значимости процесса тестирования;

• дискуссии о том, что тестировщики – лишнее звено в процессе (вроде их цель находить и оформлять баги, а они и этого не могут сделать по-человечески);

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

Ни в коем случае не хочу обидеть или запугать людей, которые только собираются окунуться в тестирование. Лично для меня тестирование – это безумно интересный и сложный мир, в котором нет места халяве и выполнению задачи на «абы как». Поэтому мне очень хочется, чтобы тестировщик следил за уровнем выполняемой работы. А уж к заведению багов вообще относился как к «святая святых».

Поэтому я решила написать памятку: «Как не надо заводить баги. Или часто встречаемые ошибки»:

1. Работа на скорость

Скорость хороша в спорте, в тестировании же стоит уделять внимание качеству. Представим следующую ситуацию: один тестировщик завел 50 багов, но по 30 из них нужны коммуникации и уточнения, а 15 можно вообще закрыть, т.к. это и не баги вовсе, а фичи или особенности, которые можно изменить в настройках браузера. Другой тестировщик завел 15 информативных багов, которые можно сразу брать в работу без отклонений и уточнений. На чьей стороне будет «победа»? Мне кажется, ответ очевиден?.

2. Отсутствие конкретики

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

3. Использование сленга при формулировке бага

Как уже говорилось в примере про «крокозябру»: если не хватает технической грамотности, Гугл в помощь. В противном случае, в глазах коллег вы будете олицетворять мальчугана с картинки: смешно и нелепо.

4.Пренебрежение примерами и скриншотами

Этот широкий жест не будет лишним и сэкономит много времени для скорейшего закрытия задачи.

P.S. Не стоит путать: скрин – нужное и дельное дополнение, но не полное описание бага. Скрин не должен заменять описание.

5. Своевременный перевод бага на разработчика

Гораздо приятнее, чтобы разработчики увидели актуальную на текущую дату и четко описанную версию бага. Это избавит от лишней траты.

6. Актуализация критериев приёмки

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

Прежде чем закрыть любую задачу (заведенный вами баг или тестируемую задачу по новому функционалу), было бы здорово потратить немного времени и, пока все свежо в памяти, собрать «крайнюю» информацию из всех источников (документация, коммуникации с коллегами, чаты, телефония) и изложить ее в критериях приемки.

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

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

7. Заведение «псевдобагов»

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

Из банальных примеров – при входе на страницу авторизации логин и пароль предлагаются автоматически. Это устранится очисткой cookies. Другой пример – кроссбраузерность. В одном браузере картинка четкая и на экране отображается прекрасно, в другом браузере – поля наезжают друг на друга. Возможно, дело в масштабе? Прежде чем бить панику, стоит сначала убедиться, что установка одинакового масштаба в обоих браузерах не устранит проблему.

8. Изменение ожидаемого результата

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

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

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

9. Неумение отличить фронт от бэка

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

Пример: в поле не работает валидация. Баг задублировался и пришел и к фронтовым, и к бэкендовым командам. Обе команды тратят время и ресурсы на то, чтобы поправить баг.

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

10. Работа с логами

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

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