Slider Background

Компромисс. Bugzilla против Word

Компромисс. Bugzilla против Word

Когда то давно у нас не было системы отслеживания багов. Потом появился большой Excel файл, а после - Bugzilla, которая и используется последние несколько лет. Когда она появилась, мы нарадоваться не могли. Все казалось упорядоченным, четким, красивым. Шло время.

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

Поэтому я начал мухлевать. У нас есть информационная система Инфоконт, установленная на нескольких десятках объектах. Когда доходят руки, я анализирую ее работу. При этом я открываю Word. Далее просто – скриншот, пояснения, скриншот, пояснения и т.д. Если нужно – я обвожу кружочками проблемные места, рисую стрелочки и т.д. В итоге появляется многостраничный документ, где баги перемежаются с предложениями по улучшению.

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

Почему я так делаю. Во-первых, я не хочу терять темп. Если я сел и начал работать, то prt-sc и ctrl-c мои лучшие друзья, они ускоряют работу в разы. Во-вторых, с распечаткой можно сесть вместе с программистом и пояснить, что ты хочешь. И, в-третьих, потом разработчик быстро внесет исправления. Общая цель - поддержка высокого темпа всей разработки.

В чем минусы. Первый, самый важный – то, что исправления не буду проверены. Второй о сделанных изменениях может никто не узнать.

Когда можно и нельзя использовать этот прием. Наверное, для разработки софта, управляющего ядерным реактором, он не очень годится. Впрочем, и для больших багов, которые имеют шанс появиться в будущем, он не применим. С другой стороны есть нестыковки в интерфейсе, мелкие детали, которые портят чудную бочку меда. Также он применим для компонентов, которые только что вышли из-под пера/клавиатуры и находятся в режиме апробирования.

Неожиданно для себя я недавно получил подтверждение своим мыслям. Теперь я не один. Наши разработчики, вернувшись с конференции Software People 2010, пошли по схожему пути и внедрили следующую практику. Теперь тестировщики не пишут баги по новым фичам и комментарии к вновь открытым багам в Bugzilla, а быстро общаются по аське, телефону или лично. Кончено, крупные и страшные баги вносятся, но их количество принципиально другое. В итоге, скорость исправления увеличилась, а писанина уменьшилась (все же знают анекдот про зайчика, волка и писанину, которая увеличилась).
« Предыдущий
Следующий »