В 90% случаев приложить скриншот в баг-репорт будет полезно.
На моих курсах мы объясняем студентам, что разработчику может быть достаточно хорошего названия бага + скриншота. Он, если код знает, сам поймет, где исправлять. А шаги уже так... Тестировщику для воспроизведения.
Так что не ленитесь. Вам его сделать раз плюнуть (просто найдите удобный скриншотер для себя), а разработчики скажут спасибо. Да и вы сами, читая задачу, быстрее вспомните, о чем речь, если есть скриншот проблемы.
Ведь картинка — это первое, что притягивает взгляд. Сначала смотрим на нее, а потом уже читаем описание. Так мы читаем книги, так же мы читаем и баги. Хороший, «говорящий» скриншот — это плюсик вам в карму.
Чтобы сделать хороший скриншот, нужно:
Любой нормальный скриншотер позволяет сделать стрелочку и добавить надпись. И, конечно же, обрезать изображение (функция «crop»). Не стесняйтесь пользоваться этим!
А то открываешь баг начинающего тестировщика и видишь там отсылку к скриншоту с сообщением об ошибке. Сообщение занимает 15% скриншота, а вокруг всякие разные вкладки, вылезшееся сообщение скайпа с любовным посланием, и другие мелочи, которые никому не нужны.
А студентам когда говоришь обрезать изображение, то иногда получаешь неумелое использование Paint — в задачу вкладывается картинка, где маленький квадратик занимает скриншот... И вокруг еще куча белого пространства. Так бывает, когда вы вставляете в Paint небольшое изображение и сразу жмете «Сохранить». А надо еще обрезать, чтобы осталась только ваша картинка.
Так что делаем сразу красивый и правильный скриншот. И наслаждамся результатом! Начнете работать и сразу заметите разницу между задачами со скриншотами и без. Они почти всегда уместны и лишь помогают.
А еще могут принести пользу. Бывает, что пытаешься воспроизвести старый баг — не воспроизводится. Если есть скриншот, можно увидеть, что раньше эта формочка выглядела вообще по другому. Так что скорее всего баг пропал при переписывании кода, задачу можно закрывать.
Особенно это касается проблем, которые зависят от графического интерфейса. Пытаемся воспроизвести, у нас все хорошо. Это баг исправили или он просто плохо описан и для воспроизведения надо сделать что-то еще? Смотрим на картинку, проверяем. Она помогает нам увидеть,как проблема выглядела раньше.
На моих курсах мы объясняем студентам, что разработчику может быть достаточно хорошего названия бага + скриншота. Он, если код знает, сам поймет, где исправлять. А шаги уже так... Тестировщику для воспроизведения.
Так что не ленитесь. Вам его сделать раз плюнуть (просто найдите удобный скриншотер для себя), а разработчики скажут спасибо. Да и вы сами, читая задачу, быстрее вспомните, о чем речь, если есть скриншот проблемы.
Ведь картинка — это первое, что притягивает взгляд. Сначала смотрим на нее, а потом уже читаем описание. Так мы читаем книги, так же мы читаем и баги. Хороший, «говорящий» скриншот — это плюсик вам в карму.
Чтобы сделать хороший скриншот, нужно:
- Отметить место, «куда смотреть».
- Обрезать все лишнее.
Любой нормальный скриншотер позволяет сделать стрелочку и добавить надпись. И, конечно же, обрезать изображение (функция «crop»). Не стесняйтесь пользоваться этим!
А то открываешь баг начинающего тестировщика и видишь там отсылку к скриншоту с сообщением об ошибке. Сообщение занимает 15% скриншота, а вокруг всякие разные вкладки, вылезшееся сообщение скайпа с любовным посланием, и другие мелочи, которые никому не нужны.
А студентам когда говоришь обрезать изображение, то иногда получаешь неумелое использование Paint — в задачу вкладывается картинка, где маленький квадратик занимает скриншот... И вокруг еще куча белого пространства. Так бывает, когда вы вставляете в Paint небольшое изображение и сразу жмете «Сохранить». А надо еще обрезать, чтобы осталась только ваша картинка.
Так что делаем сразу красивый и правильный скриншот. И наслаждамся результатом! Начнете работать и сразу заметите разницу между задачами со скриншотами и без. Они почти всегда уместны и лишь помогают.
А еще могут принести пользу. Бывает, что пытаешься воспроизвести старый баг — не воспроизводится. Если есть скриншот, можно увидеть, что раньше эта формочка выглядела вообще по другому. Так что скорее всего баг пропал при переписывании кода, задачу можно закрывать.
Особенно это касается проблем, которые зависят от графического интерфейса. Пытаемся воспроизвести, у нас все хорошо. Это баг исправили или он просто плохо описан и для воспроизведения надо сделать что-то еще? Смотрим на картинку, проверяем. Она помогает нам увидеть,как проблема выглядела раньше.
См также:
Первое правило аттачей в багах — говорящее название!
Вложил аттач? Сошлись на него по тексту бага
Первое правило аттачей в багах — говорящее название!
Вложил аттач? Сошлись на него по тексту бага
Как заводить задачи в баг-трекер — что еще нужно, кроме скриншота
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
на счет обрезать лишнее тут очень спорно, часто нужно уточнять где это именно находится или бегать с этим кусочком как с пазлом искать куда подойдет.
ОтветитьУдалитьРазумеется, не стоит с водой выплескивать ребенка и убирать понятность скриншота :) Но это не значит, что всем нужно видеть твой рабочий стол, открытые вкладки, да и внутри системы часто можно сделать обрезку поменьше
Удалить> В 90% случаев приложить скриншот в баг-репорт будет полезно.
ОтветитьУдалитьПри условии, что вы тестируете верстку.
Если тестируем API + 100500 случаев, скриншот, мягко говоря, неуместен.
PS. А описания лучше избегать. Но для этого опыта нужно много.
Когда верстку — скрин обязателен. В остальных случаях все равно полезен, даже если проблема НЕ в верстке. Есть, конечно, исключения в виде тестирования АПИ, где просто нечего скриншотить — но их мало, особенно среди новичков. Про 100500 случаев тоже очень спорно)
Удалить