Home

Автор: Евгений Ткаченко

В современном IT мире Bug tracking системы уже не столько помогают, как мешают продуктовой команде развиваться. Когда все общение по проблемам происходит через такие системы теряется коммуникативная связь между тестировщиками, разработчиками и заказчиками. Все обсуждения в рамках задач в карточках занимают непростительно много времени, которое можно было потратить более эффективно. Да и вообще само название такого продукта как "Bug tracking система" несет негативный посыл, ведь все команды стремятся, чтобы багов в их проектах не было.

Так где же мы храним эти баги?

Джира, Багзила , Мантис, Редмайн, Берт, Трелло, Мингл, а может кто то использовал Гугл доки или Гугл таблицы для этого, думаю еще есть варианты.

Каждый из нас работает с Багтрекинг системами или когда либо работал в прошлом.

Как же мы с ними работаем?

Стандартная зарисовка из жизни:

Тестировщик, проверяя очередной новый функционал продукта, сталкивается с некорректным поведением в нем. Конечно же он начинает локализовывать причины его появления и по результатам этого заводит таск в системе.

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

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

В такой ситуации тратится двойное время на запись-воспроизведение, ошибки где то складируются , теряется фокус.

Давайте теперь сфантазируем другую картину:

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

Потом этот автотест добавляется в число регрессивных и больше это ошибка никогда не пройдет!

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

А как насчет отслеживания статистики по работе каждого из программистов и тестировщиков. "Чем больше багов тестировщик нашел тем он лучше." Думаю , вы все слышали это выражение, а многие и сами употребляли в своей речи.

Конечно же это не так, ведь главная цель это предотвратить ошибки, а не обнаружить их как можно больше!

В одном из проектов компании в которой я до этого работал мы использовали в качестве багтрекинга Берт, он был предоставлен нашими заказчиками, которые находились в Америке и этот инструмент им был удобен. Он был ни чем не примечателен: таже громоздкая джира только с еще менее дружелюбным интерфейсом.

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

Реализовано это было тоже с помощью гугл таблиц, в которые вносилась информация: номер задачи в Берте, момент времени изменения статуса задачи и имя ответственных за эту задачу (тестировщик и разработчик). Статус задачи имел произвольные категории. Пример: Задача создана (разработчик извещен о проблеме) в 12:50 21 декабря, следующий статус: 16:30 разработчик запросил более полное описание проблемы, задача возвращена на повторное исследование. 22 декабря 11:40 задача возвращена с новыми данными, 22 декабря 16:00 задача разрешена. Эта таблица была доступна только для отдела кау и для продукт менеджера.

Таким образом собиралась статистика об эффективности работы разработчиков и взаимодействия их с тестировщиками, которого за исключением общения в системе багтрекинга не было как такового.

По результатам полугода использования такой система, накопленная информация не принесла ни какой пользы и не продвинуло абсолютно команду к той всеобщей цели: качество продукта, а только уходило внутрикомандную обстановку. Такие действия со стороны менеджмента только создают прецеденты для разжигания вражды между тестировщиками и разработчиками. Ведь первые без коммуникаций втихую отписывают менеджменту о том что их багом не занимаются вместо прямого общения и выяснения причин этого.

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

Мы выработали некоторые правила как работать с этим инструментом и их придерживаемся:

• мы используем 'Trello' для наших задач и ничего особенного для багов;
• мы используем 'Trello' только для багов с продакшен;
• мы придерживаемся принципа “нулевой терпимости к багам” (не выпускаем продукт пока в нем есть ошибки);
• вместо логирования ошибок, мы пишем автотесты для воспроизведения их;
• мы придерживаемся принципа "Не больше 10 багов в тайнике" (багов на продакшен не должно быть больше 10 в любой момент времени);
• мы стремимся к полному покрытию функционала тестами со всех сторон.

Для нас это работает, чего и вам желаю!

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