На что обращаться внимание, когда вы пишете шаги бага? Есть несколько разных правил, одно из которых — «опиши и приложи». Не забывайте про скриншоты и примеры!
Почему в моей книге столько картинок? Потому что они привлекают внимание! Это первое, за что цепляется взгляд.
Хорошо оформленный баг — это когда разработчик прочитал название, посмотрел на скриншот и все. Ему больше ничего не нужно, он понял, где ошибка. А шаги... Шаги остаются тестировщику для перепроверки задачи.
Пример — это не только какое-то значение, которые мы вводим в строку: «Например, 6,9»
Это может быть файл, на котором воспроизодится баг. Или SOAP-запрос, с помощью которого вы нашли проблему. Вложите это все в баг-трекер, пригодится.
Читая такую задачу, я сразу вижу локализацию. И, что важнее, легко могу воспроизвести ошибку. Не бегая при этом среди тестировщиков с вопросом «У кого есть корректный файл на 20+ Мб весом??».
Или ситуация с запросом:
Вот запросы как раз редко вкладывают. Потому что они обычно есть — в примерах в документации, в автотестах, в сохраненных тестовых данных. Но... Это ведь надо пойти и найти нужный запрос, скорректировать под свою ситуацию. Зачем тратить время?
Я сама столкнулась с такой проблемой. Описала баг через «Создать нового клиента с мобильным телефоном». Все знают, что это значит. У нас есть примеры вызова. Но примеры — общие. А у тебя конкретный заказчик, у которого одно поле называется по другому, другого вообще нет. Поэтому да, можно взять пример и подкрячить под себя, но это время...
Пару раз пришлось спустя неделю снова воспроизводить свои же баги. После этого я стала прикладывать конкретный пример запроса. Если коротенький — то прямо внутри комментарий. Если запрос длинный, то я сохраняла его в файлик и вкладывала в задачу.
Поверьте, это ОЧЕНЬ упрощает жизнь. По опыту говорю 😊
См также:
Скриншоты
Почему в моей книге столько картинок? Потому что они привлекают внимание! Это первое, за что цепляется взгляд.
Хорошо оформленный баг — это когда разработчик прочитал название, посмотрел на скриншот и все. Ему больше ничего не нужно, он понял, где ошибка. А шаги... Шаги остаются тестировщику для перепроверки задачи.
Примеры
Пример — это не только какое-то значение, которые мы вводим в строку: «Например, 6,9»
Это может быть файл, на котором воспроизодится баг. Или SOAP-запрос, с помощью которого вы нашли проблему. Вложите это все в баг-трекер, пригодится.
Загрузить файл
↓
Загрузить файл весом более 20Мб (Например, см аттач more_then_20mb.csv)
Читая такую задачу, я сразу вижу локализацию. И, что важнее, легко могу воспроизвести ошибку. Не бегая при этом среди тестировщиков с вопросом «У кого есть корректный файл на 20+ Мб весом??».
Или ситуация с запросом:
Послать save-запрос
↓
С помощью save-запроса создать нового клиента.
…
Доп инфо — использовался запрос SAVE.txt, см аттач
Вот запросы как раз редко вкладывают. Потому что они обычно есть — в примерах в документации, в автотестах, в сохраненных тестовых данных. Но... Это ведь надо пойти и найти нужный запрос, скорректировать под свою ситуацию. Зачем тратить время?
Я сама столкнулась с такой проблемой. Описала баг через «Создать нового клиента с мобильным телефоном». Все знают, что это значит. У нас есть примеры вызова. Но примеры — общие. А у тебя конкретный заказчик, у которого одно поле называется по другому, другого вообще нет. Поэтому да, можно взять пример и подкрячить под себя, но это время...
Пару раз пришлось спустя неделю снова воспроизводить свои же баги. После этого я стала прикладывать конкретный пример запроса. Если коротенький — то прямо внутри комментарий. Если запрос длинный, то я сохраняла его в файлик и вкладывала в задачу.
Поверьте, это ОЧЕНЬ упрощает жизнь. По опыту говорю 😊
Типичная ошибка
Подготовка файла как пред. шаги
Баг — не тест-кейс, разработчику предварительные шаги не нужны. Он не будет готовить файл, это ваша работа. Он лучше возьмет готовый. Поэтому убираем подготовительные шаги и описываем локализацию (что за файл) в тот момент, когда на него ссылаемся:
1. Готовим файл A.jpg
2. Грузим его в систему
↓
Загрузить файл весом более 20Мб (Например, см аттач more_then_20mb.csv)
См также:
Как заводить задачи в баг-трекер — в целом о заведении задачи
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Комментариев нет:
Отправить комментарий