«

»

Май 28

Мысли о баг-репортах. Часть III. «Attachment» оно же «Вложение»

Часть II.2 здесь.

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

  1. Что присоединяется к баг-репорту.
  2. Зачем и как это присоединяется к отчету об ошибке.
  3. Как называется это вложение.

Что может быть присоединено к баг-репорту

Файл.

Логично. А какой файл?
1. Это может быть графический файл (файл содержащий изображение).
2. Это может быть видео-файл.
3. Это может быть документ (текстовый, электронные таблицы, текстовые логи).
4. Это могут быть различные дампы (памяти).
5. Архивы содержащие все вышеперечисленное.

Зачем и как это присоединяется к отчету об ошибке.

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

Скриншот (Screenshot)

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

Но во всем надо знать меру. Если необходимо изображение меню приложения, то нет необходимости фотографировать на фотоаппарат монитор и изображение на нем и, приложив его к дефекту, указывать: «на экране ошибка в меню».
Да, бывают случаи, когда скриншот ошибки — это именно фотоснимок какого-нибудь устройства с приложением, например автоматы оплаты, коих полно в каждом магазине. Но не стоит это брать за правило для всех приложений 🙂

Видео-запись

Некоторые дефекты имеют очень и очень сложные шаги для воспроизведения. Некоторые дефекты не могут быть локализованы в разумные временные промежутки. Некоторые дефекты могут иметь 20-30 шагов для воспроизведения. Заставлять читать эти шаги — не очень гуманно.
А может случится и так, что есть языковой барьер между тем, кто сообщает об ошибке и прочими участниками разработки. Я понимаю, что прекрасный английский, беглый немецкий и итальянский со словарем — это чудесно, но… Не все могут понять шекспировский язык, особенно не носители языка. Если для описания шагов воспроизведения необходимо написать полотно текста, даже на родном Вам языке, и читать его будут носители этого же языка, сделайте видео-запись процесса воспроизведения. И даже, может быть, сократите поле описания (description) в баг-репорте.

Документы

Будь то спецификации, будь то письма, будь то чеклисты — полезно добавить к описанию дефекта эти документы, конечно же, если они к нему относятся 😉

Приложения и операционная система могут писать логи. Возьмите лог и присоедините к дефекту.
Это не было бы так смешно, если бы не было грустно. Мой товарищ, работающий в саппорте, рассказал недавно душещипательную историю: «Пришла жалоба от клиента. Окей, вроде поняли в чем дело, но нужно было уточнить по логам приложения. Звоню дядьке этому. Поговорили, договорились — он вышлет логи. Выслал. Скриншот. Скриншот лога. Он его открыл, сделал снимок экрана и прислал».
Так вот, не надо стесняться полностью лог присоединить, если проблема в размере файла лога: можно заархивировать его (об архивации отдельный разговор ниже), можно, в крайнем случае, скопировать текст из лога, за последнии активности, которые относятся к дефекту, в текстовый файл и присоединить уже этот файл.

Или, например, у вас есть замечательный отчет о тестировании производительности. Куча цифр, графиков. Соберите нормальный файл в Excel, например, и присоедините его. Не надо присоединять 20 файлов и предлагать поиграть в сборку пазла тем, кто будет просматривать дефект. Или тестировать его. IT-мир маленький. Вас могут найти и сказать «Бу!», за подобное 🙂

Дампы

Если у вас есть возможность вытянуть дамп памяти приложения, возьмите и добавьте его к описанию дефекта. Да, к косметическим дефектам, это не очень нужно, но ведь дефекты бывают не только в оформлении.

Архивы

С архивами тоже не всё так просто. Да, закинуть файлы, которые нужны в одну папку, сжать это RAR(ом), не сложно.  Вот только не у всех стоит RAR, и да, не все эту утилиту могут поставить себе. Не все готовы платить за её использование (Вы же в курсе, что за использование этого архиватора надо платить?). Zip  — замечательный формат. Чем вы сожмете файл и получите этот формат — не так важно, как то, что практически везде этот формат можно будет открыть, не используя дополнительных утилит.

 

Как называть это вложение

«1.txt», «Ошибка.jpg», «MainPageError.jpg» и прочие «говорящие» названия хороши для блокбастеров.

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

Просто представьте, что все ваши вложения сохранены у вас в папке, и вам необходимо найти скрин определенной проблемы, а баг-трекер лежит на тех.обслуживании, например. Мозг не вскипит?:)

Простое название bigProblem.jpg — это хорошо. Но всё-таки, более гуманно по отношению к себе и всему остальному человечеству использовать названия вида: [BugID_ProductName_Feature]_TypeOfProblem.txt
Это не строгое правило, нет. Но хочется надеяться, что общий подход к наименованию файлов ясен.

Спасибо вам за то, что дочитали до этого момента. На этом серию о баг-репорте я позволю себе закончить.

О таких вещах как приоритет (priority) и серьезность (severity), например, говорить стоит не только в рамках bug-reporting(а). О них напишу, конечно же, но позже. 🙂

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Яндекс

5 комментариев

2 пинга

Перейти полю для комментария

  1. Алексей Фёдоров

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

  2. oleg

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

    А вот заставлять тестировщика сочинять заголовки к аттачам в виде «[BugID-223]Offence_SaveAs_HandledException_WrongFileAccess.jpg» — это точно негуманно 🙂

    1. Сергей Атрощенков

      Почему же неразумно?
      Иногда, проще найти скрин по названию, чем искать по базе или по багтрекеру дефект, о котором идет речь. И из скрина уже выцепить bug ID.

      По поводу негуманности… Работа у нас такая 🙂
      У меня, аттаче на 10-15, подобное наименование стало на уровне автоматизма. Да и выдумывать ведь не надо ничего.
      Но вот после перерыва (отпуска, например), вернуться к громоздким названиям, вместо старого доброго Еггог.png было очень тяжело.
      Ведь багов много, а я тут сижу, и «писательством» занимаюсь. 🙂

  3. oleg

    От себя добавлю по поводу скриншотов — не нужно сохранять скрины в BMP формат (который обычно весит несколько мегабайт). Есть jpeg, png

    1. Сергей Атрощенков

      Отличное уточнение, спасибо 🙂
      Добавил в файлик.

  1. Итоговое руководство по составлению отчетов об ошибках. | BarbaricQA.com

    […] Мысли о баг-репортах. Часть III. «Attachment» оно же «Вложение… […]

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Вы можете использовать эти теги HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>