Сначала приведем пару примеров :)
Итак первый баг - «Вот в эту систему захожу и нажимаю отключить»
Бывает так, что нам, тестировщикам, кажется очевидным и простым – для других сотрудников не так, ведь они одновременно работают с различными системами. Им из-за неудовлетворительного качества бага придется потратить время на уточнение, о чем вообще идет речь (какой продукт, какая среда, какая система и тд).
Еще один пример: «При кодировке UTF 8 русские слова переносятся кракозябрами»
Единственное, что хочется сказать после прочитанного – кракозябра вполне может быть милой :) Да, в настоящее время IT-специалисты, понимают, что хотел сказать автор данного бага. Но тут уже возникает вопрос отношения к коллегам и работе. Ведь намного лучше затратить чуть больше времени и вместо «панибратских» выражений технически грамотно описать проблему?
И дабы сохранить престиж работы и быть настоящим специалистом своего дела, предлагаем разобрать часто встречающиеся ошибки при написании багрепортов:
1. Работа на скорость
Скорость хороша в спорте, в тестировании же стоит уделять внимание качеству. Представим следующую ситуацию: один тестировщик завел 50 багов, но по 30 из них нужны коммуникации и уточнения, а 15 можно вообще закрыть, т.к. это и не баги вовсе, а фичи или особенности, которые можно изменить в настройках браузера. Другой тестировщик завел 15 информативных багов, которые можно сразу брать в работу без отклонений и уточнений. На чьей стороне будет «победа»? Ответ очевиден, верно? :)
2. Отсутствие конкретики
В дополнение к первому пункту: баг должен быть понятен разработчику настолько, что у него не возникнет необходимости писать вам и задавать дополнительные вопросы.
Общие слова «не работает», «некорректно», «не красиво», «не правильно» лучше не использовать, так как они не дают понимания в чем именно состоит баг)
3. Использование сленга при формулировке бага
Как уже говорилось в примере про «крокозябру»: если не хватает технической грамотности, поможет Гугл. Также можно описать своими словами так, чтобы было понятно где и что находится.
4.Пренебрежение примерами и скриншотами
Этот широкий жест не будет лишним и сэкономит много времени для скорейшего закрытия задачи.
P.S. Не стоит путать: скрин – нужное и дельное дополнение, но не полное описание бага. Скрин не должен заменять описание.
5. Своевременный перевод бага на разработчика
Не откладывайте дела на потом :) Гораздо приятнее, чтобы разработчики увидели актуальную на текущую дату и четко описанную версию бага. Это избавит от лишней траты.
6. Заведение «псевдобагов»
Под «псевдобагами» мы подразумеваем особенности тестовой среды или параметры, которые можно отключить в настройках браузера.
Из банальных примеров – при входе на страницу авторизации логин и пароль предлагаются автоматически. Это устранится очисткой cookies. Другой пример – кроссбраузерность. В одном браузере картинка четкая и на экране отображается прекрасно, в другом браузере – поля наезжают друг на друга. Возможно, дело в масштабе? Прежде чем бить панику, стоит сначала убедиться, что установка одинакового масштаба в обоих браузерах не устранит проблему.
Еще один пример -автоперевод браузера. Например мы зашли на англоязычный сайт и включили перевод на русский. Заводить багрепорты с переводом в таком случае не нужно, так как к функционалу самого сайта это не имеет никакого отношения
7. Изменение ожидаемого результата
Бывают случаи, когда тестировщику не хватило информации для полного понимания процесса (отсутствие или наличие недостаточной/ слабый анализ). И может возникнуть такая ситуация, что через какое-то время после заведения бага выяснится, что ожидаемый результат, который вы указали, неверный. Он должен быть другим. И вот тут начинается самое интересное: тестировщик, чтобы замести следы «преступления» удаляет описание ожидаемого результата или (что еще хуже) начинает препираться с разработчиком, что подразумевалось другое.
Допустить ошибку - это нормальная рабочая ситуация. Не надо бояться её признать и исправить: либо закрыть задачу с соответствующими пометками и создать новую с актуальной информацией, либо по согласованию с командой изменить описание в текущей задаче.
Другая жизненная ситуация – заведение бага без ожидаемого результата. В таком случае надо пенять на себя и осознавать, что разработчик поправит так, как он поймет из описания. И далеко не факт, что правка будет совпадать с тем, чего вы ожидали. И отклонять решенную задачу с претензией, что вы ожидали «чего-то другого» будет непрофессионально. Поэтому все свои ожидания и пожелания надо обязательно указывать в критериях приемки.
8. Пренебрежение шагами
Разработчик должен в точности повторить ваши шаги и воспроизвести баг, поэтому описывая баг представляйте, что объясняете ребенку:
- Открыть главную страницу
- Перейти в раздел ….
- Нажать на .…
и так далее)
9. Много лишнего и «воды»
Запомните простые правила:
Действия наподобие (посмотреть/найти/подумать/обратить внимание – лучше не писать в шагах)
Соблюдайте принцип обезличенности: формируйте слова в начальной форме (нажать/открыть/перейти/ввести и т.д.)
Один шаг = одно действие (перейти, открыть, зайти и т.д.)
Работа тестировщика напрямую и неотъемлемо связана с багами: мы их обнаруживаем, заводим в баг-трекинговые системы, контролируем их устранение. Поэтому очень важно правильно их заводить, ведь без них никуда. Баги –жизненно необходимый орган в процессе системы. Постарайтесь внимательнее их заводить, тогда всем станет лучше :)
А узнать больше о тестировании вы можете на бесплатном практическом уроке. Записаться можно по ссылке: https://be-tester.ru/freeonline