Инструменты баг-трекинга

На самом деле в качестве инструментов баг-трекинга можно использовать все, что угодно:

• Гуглодоку
• Ворд
• Скайп
• Почту
• ...

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

Самодельные инструменты

Почта

На первой работе мы тестировали игрушки для мобильных приложений. Это было больше 10 лет назад . Если видели ошибки, то создавали письмо в почте, туда прикладывали шаги, скриншоты (Ну как скриншоты... фоточки! У нас был специальный фотоаппарат для этого, на тех телефонах еще не было снимков экранов), и отправляли разработчику.

Разработчик отвечал на каждое письмо, где подписывал у каждой ошибки статус: починил / деклайн (не баг). Тестировщик получал письмо и должен был сразу проверить исправление. Иначе можно легко забыть, что что-то правилось. Ну или настраивать как-то специально почту «вот это письмо прочитано, но не проверено» итд, но таким мы не заморачивались.


Новички обновлять версии не умели, поэтому шли к начальнику с телефоном. Тот обновлял сборку, мы проверяли фикс  и писали ответ на письмо разработчика — все проверено, ок. Или «вот это и это до сих пор не работает, вот новые скрины».

Конечно, это не самый удобный инструмент, разработчик периодически получал дубли... Но тем не менее оно работало! Уж не знаю, почем не было «нормального» инструмента. Возможно, о таких просто еще никто с работы моей не слышал. А может, что-то уже существовало, но не захотели платить или заморачиваться с настройкой. И так ведь работает!


Ворд

Потом я работала в небольшом стартапе. Я уже знала о существовании джиры и всячески уговаривала ее подключить и настроить. Ребята были против:

• JIRA платная, но на небольшую компанию до 10 человек это стоит всего 10 долларов в месяц, на что и был упор в моих доводах.
• Настраивать неохота, времени тратить жаль — но тут я готова была ее настроить сама.

Тем не менее какое-то время мы жили с багами в ворде. Да-да, в простом ворде!

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

Я проверяла по файлу. Потом или дополняла его, или создавала новый файл, куда писала новые проблемы + копировала недоисправленные. Очень неудобно было, хочу вам сказать =) Но жили же как-то...

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

Специализированные инструменты

Сначала список удобных и «красивых» инструментов :

• JIRA — платная, но крутая;
• Redmine — основной конкурент, бесплатный;
• Youtrack — чем-то похож на JIRA, но менее распространен;

Менее удобные, но относительно популярные (2018 год):

• Mantis — в целом не так уж плох, но не сравнится с JIRA или Redmine;
• Bugzilla — она вообще не конкурент, но если не верите… Тут даже отредактировать задачу нельзя, только новый комментарий написать;
• Trac — как по мне, так вообще убожество, там надо писать в HTML-разметке, а зачем заморачиваться, если даже в гуглодоке и то про это думать не надо?

Если у вас еще нет никакого инструмента на работе, предложите установить какой-нибудь. Лично я фанат JIRA, она мне кажется простой и удобной. Тем более что в облачной версии все можно создать-настроить в пару кликов и работать из коробки. А вот редмайн чтобы стал удобным, с ним надо повозиться администратору...

В любом случае вы можете попробовать парочку разных инструментов, чтобы сделать выбор. Какой понравится, тот и ставьте. Обычно в инструментах есть trial-версия (попробуй бесплатно 1 месяц), используйте ее.

Ну или тестовые площадки, находящиеся в открытом доступе. Например, на Testbase есть такие: http://testbase.ru/test-it. Все равно мне нужны были инструменты для моего курса, дать студентам пощупать. Почему бы не выложить в общий доступ? Конечно, мои площадки действуют на момент прочтения вами этого поста и кто знает, что будет лет через 5-10... Инструменты могут устареть или закрыться, открытый доступ может закончиться...

В общем, если есть где пощупать — используйте варианты! Они обычно легко гуглятся. Да и trial-версия никому не мешала. Пробуйте, выбирайте, все в ваших руках.

Преимущества инструментов

Инструменты отслеживания ошибок  нужны для наглядной работы:

1. Вы видите, в каком статусе проект сейчас — сколько задач всего, сколько из них в разработке, сколько в тестировании.
2. Вы видите всю историю бага — с чего все начиналось, чем закончилось, что нашли в процессе.
3. Вы видите вообще все найденные ранее баги — а история тоже бывает полезна.
4. Можно настроить инструмент под себя

Статус проекта

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

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

История одного бага

Вроде кажется, что это все неважно. Ну был и был баг, подумаешь! Главное, что исправили. А раз исправили — можно забыть. Но нет.

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

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

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

Или другая история — приходит заказчик с проблемой. А я смутно помню, что мы это уже исправляли. Но как именно — не знаю, забыла уже. Нахожу баг в джире, читаю как исправили. Ну вот ответ и готов! Просто заказчик обновил сервер приложения, но не применил какую-то настройку. Не будь истории бага, пришлось бы снова тратить время на разбор полетов и выяснение, как починить. Полдня вместо 5 минут.

Иногда история подскажет, почему задачу решили НЕ делать. А то бывает и такое, что приходит к тебе менеджер с вопросом «Почему ты не нашел этот баг?!», а ты находил. Просто его отказались чинить: «никто так делать не будет». Причем сам менеджер ее и закрыл с таким комментарием, просто забыл. А когда пользователи все же сделали «так», претензии идут к команде — почему не нашли, почему не починили? Находите задачу в баг-трекере, показываете ее — все, ваша совесть чиста.

История всех задач

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

Или, возможно, баг уже поставил ваш коллега и ошибку исправили в текущем релизе. Или не исправили, а выкинули во «future iteration», потому что она некритичная. В любом случае вы НЕ заводите дубликат,  а это хорошо, зачем засорять баг-трекер?


Гибкая настройка

Не хватает какого-то поля? Вошли в админку, добавили.
Хочется изменить жизненный цикл задачи — не вопрос.

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


Итого преимущества

• Наглядность — сразу виден статус релиза, сколько сделано, сколько осталось
• Хранилище коллективной памяти
• Поиск по базе
• Гибкая настройка

См также:

Как заводить задачи в баг-трекер → подробнее о том, как ставить задачу и заполнять обязательные поля.

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