Идеальное состояние багтрекера

Идеальная техническая система -это когда системы нет, а ее функция выполняется.

(с) ТРИЗ

Ряд авторов называют наличие бактрекера в качестве одного из признаков зрелости команды разработчиков ПО.

Действительно, множество растущих команд (компаний) в какой-то момент сталкиваются примерно с одной и той же проблемой. Список дефектов растет и в какой-то момент требуется специализированное средство для управлением порядком исправления. С пятком багов можно легко справиться при помощи почтового клиента. Полсотни багов можно вести в Excel. Но когда их пара тысяч – это уже многовато. И каждый «настоящий» инженер по качеству ПО (в просторечии тестировщик) знает, что по настоящему бороться за качество без бактрекера нельзя. Это догмат. Доктрина веры. Нет бактрекера – нет настоящих инженеров по качеству ПО. Чистая кристальная истина, в которой нельзя усомниться ни на секунду, как нельзя не услышать звук хлопка одной ладонью. А если 20 лет назад выпускались великолепные программы, без использования багтрекинга, то это просто ошибка наблюдения.

Но иногда встречаются «не настоящие».

Из книги Мэри и Тома Поппендик «Бережливое производство программного обеспечения»:

…возможны две разновидности контроля: контроль с целью обнаружения дефекта (когда он уже имеется) и контроль с целью его предотвращения…

Системы …[багтрекеры] – это очереди незавершенных работ; если угодно, очереди работ, … [на] исправление. Очень часто мы полагаем, что если дефект помещен в очередь, все в порядке, он уже никуда не денется. Однако с точки зрения концепции бережливой разработки программного обеспечения, очереди – это коллекторы непроизводительных затрат. Целью является не иметь в очереди ни одного дефекта, а еще более «целесообразная цель» - не иметь такой очереди совсем. Если вы считаете, что это невозможно представить, познакомьтесь с трехгодичным опытом работы Нэнси Ван Шундерворт над проектом по разработке сложного и часто изменяющегося встроенного программного обеспечения. За три года был в целом обнаружен 51 дефект после блочного (или модульного) тестирования, причем каждый раз выявлялось не более двух дефектов сразу. Кому нужна система отслеживания для всего двух дефектов?

Примечание. Перевод я немного поправил. Совсем чуть-чуть. Только явные ляпы.

Действительно, зачем фиксировать дефект в трекере?! Его не фиксировать надо, а исправлять. Нашли и сразу дустом его, дустом. Чтобы не размножался. На первый взгляд остается непонятным, что делать с тестировщиками. Основной артефакт, который выдают тестировщики – это список расхождений между ожиданиями и реальностью. Но пусть вас не смущает этот вопрос. Там где по настоящему пекутся о качестве, там работают не тестировщики, а инженеры по качеству ПО, которые преимущественно занимаются верификацией не скомписированного кода, но других артефактов, таких как: «требования», «диаграммы архитектуры», «исходный код».

Искать ошибки после написания кода – это как делать бэкапы уже после потери операционной базы сбербанка. В принципе полезно, но несколько поздновато. Дефекты имеет смысл искать или до написания кода, или во время оного. Но не после.

Благодарности.

Спасибо Мери и Тому Попендик, Элияху Голдратту, Тайичи Оно и Капитану Очевидность.

Комментариев: 10

  1. Sergey Vysotsky написал:

    Challenge your assumptions хорошая эвристика, да. Не только для тестирования.

    В частности предположение о том что основной артефакт это “список расхождений между ожиданиями и реальностью” (для краткости “багрепорты”) так же стоит подвергнуть сомнению. Причем основательно, т.к. “ожидания”

  2. SALar написал:

    > …так же стоит подвергнуть сомнению. Причем основательно, т.к. “ожидания”
    Подвергайте. Для того блоги и существуют. ;-)

    Что касается термина “ожидания”, то он более точен, нежели “требования”. Здесь я использовал нотацию Коберна, которая расширяет модель Якобсона “Акторы и цели”. Это более точно, но чуть менее понятно, т.к. требует от читателя знания нотации. Видимо, стоило поступиться точностью в пользу понятности.

  3. Pollyanna написал:

    > “Целью является не иметь в очереди ни одного дефекта, а еще более «целесообразная цель» - не иметь такой очереди совсем.”

    имхо, целью коммерческого проекта является не пустая очередь багов, а прибыль, получаемая за продукт. Вопрос не в том, чтобы иметь не более 2х открытых дефектов, а в том, чтобы уменьшить затраты и увеличить прибыль. Уменьшение затрат путем ликвидации очереди дефектов оказалось возможно в специфическом случае (встроенное ПО, упомянутое в посте). Но у меня вызывает сомнение, что описанный подход применим ко всякому ПО. В сложных настольных распределенных системах невозможно найти все баги на уровне модульного тестирования. Очень много проблем возникает на уровне интеграции модулей. И на системном уровне. И при взаимодействии с окружением. И так далее. И исправлять все дефекты может быть просто не нужно, т.к. затраты на исправление себя не окупят.

    Кроме того, возможность иметь историю дефектов, пусть даже уже исправленных, может пригодиться, если вы проводите у себя post mortem анализ или используете наработки из одного проекта в другом.

  4. Sergey Vysotsky написал:

    Там продолжение с треугольником было. Оно почему-то не попало. По сути требования тоже ожидания, просто вполне конкретных лиц, а не всех кого нужно/можно.

  5. SALar написал:

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

    > а в том, чтобы уменьшить затраты и увеличить прибыль.
    Хочу вас огорчить. В современной разработке софта уменьшение затрат очень слабо сказывается на прибыли. А вот уменьшение времени выполнения заказа сильно.

    > Уменьшение затрат путем ликвидации очереди дефектов оказалось возможно в специфическом случае (встроенное ПО, упомянутое в посте). Но у меня вызывает сомнение, что описанный подход применим ко всякому ПО.
    К большей части применим. Проблема не в софте, а внизком уровне культуры разработки ПО. Подавляющее большинство команд вряд ли смогут так работать без нескольких лет обучения.

    > Очень много проблем возникает на уровне интеграции модулей. И на системном уровне. И при взаимодействии с окружением. И так далее.
    И что? Их что нельзя искать более высокоровневыми юнит тестами?

    > И исправлять все дефекты может быть просто не нужно, т.к. затраты на исправление себя не окупят.
    Здесь я просто отсылаю вас к книге Деменга “Выход из кризиса”. Как вариант, используйте подход: “Если баг не надо править, то его не надо фиксировать”.

    > Кроме того, возможность иметь историю дефектов, пусть даже уже исправленных, может пригодиться, если вы проводите у себя post mortem анализ или используете наработки из одного проекта в другом.
    Здесь зависимость должна быть обратная. Пост мортен анализ нужен для предотвращения дефектов, а не дефекты нужны для анализа. Не путайте причину и следствие.

  6. Pollyanna написал:

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

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

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

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

    4) запись о дефекте позволяет тестировщику проверить исправление этого дефекта. И сделать это в удобное время (например, в следующей запланированной сборке), а не заставлять программиста пересобирать и выдавать новый билд после каждого бага.

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

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

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

    >Хочу вас огорчить. В современной разработке софта уменьшение затрат очень слабо сказывается на прибыли. А вот уменьшение времени выполнения заказа сильно.

    Тогда вы сами подтверждаете, что отказ от баг-трекера нецелесообразен.
    Ведь в посте предлагается отказаться от баг-трекера и очереди дефектов именно с целью снижения затрат ( «с точки зрения концепции бережливой разработки программного обеспечения, очереди – это коллекторы непроизводительных затрат.»).
    В то же время грамотная работа с баг-трекером позволит недопустить хаос, который возникнет при наличии большого количества недокументированных и неотслеживаемых дефектов. Хаос непредсказуем и обычно не способствует уменьшению времени выполнения заказа. Баг-трекер вносит организованность, и если вы хотите сократить время выполнения заказа, он может помочь выявить наиболее проблемные части ПО, расставить приоритеты, спрогнозировать время, нужное на исправления и т.д.

    > Очень много проблем возникает на уровне интеграции модулей. И на системном уровне. >И при взаимодействии с окружением. И так далее.
    >И что? Их что нельзя искать более высокоровневыми юнит тестами?

    Нельзя. Юнит тесты – это низкоуровневые тесты. Далеко не всегда их достаточно. Если ПО сложное, то отказ от высокоуровнего тестирования может привести к пропусканию критических багов в релиз. В посте же указано, что в проекте от высокоуровневого тестирования отказались, остались на уровне юнит тестов.

    > И исправлять все дефекты может быть просто не нужно, т.к. затраты на исправление себя не окупят.
    > Здесь я просто отсылаю вас к книге Деменга “Выход из кризиса”. Как вариант, используйте подход: “Если баг не надо править, то его не надо фиксировать”.

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

    > Кроме того, возможность иметь историю дефектов, пусть даже уже исправленных, может пригодиться, если вы проводите у себя post mortem анализ или используете наработки из одного проекта в другом.
    >Здесь зависимость должна быть обратная. Пост мортен анализ нужен для предотвращения дефектов, а не дефекты нужны для анализа. Не путайте причину и следствие.

    Я не путаю причину и следствие. Не дефекты нужны для анализа, а сведения о них. Речь о том, что если проблемы были и документировались, у вас будет больше материала для post mortem анализа, чем если дефекты все равно были, но не документировались.

  7. SALar написал:

    > 1) в сложных системах дефектов много, больше, чем 2 открытых одновременно.
    При текущем подходе к качеству и в простых системах дефектов больше. Как это противоречит тезису “Если дефектов мало, то выделенное средство не нужно.”

    > 2) если в проекте задачи на программистов распределяет тех лид или ПМ, он должен сначала ознакомиться с дефектом,
    Зачем вам простой диспечер за такую зарплату?

    > 3) запись о дефекте (шаги воспроизведения, логии, скриншоты) позволяет программисту
    приступить к исправлению тогда, когда ему удобно, а не бросать работу посредине,
    Что противоречит парадигме “останов линии”, применяемой Тойота. Но к их уровню нам еще идти и идти.

    > 4) запись о дефекте позволяет тестировщику проверить исправление этого дефекта. И сделать это в удобное время (например, в следующей запланированной сборке), а не заставлять программиста пересобирать и выдавать новый билд после каждого бага.
    Э-э-э… В этом то весь и смысл. Производственная система Тойота предполагает, что на участках не являющихся ограничениями системы нужно или уменьшать размер партии, или уменьшать время переключения. Это конечно же противоречит устаревшей концепции “эффективно обоснованный размер партии”. Но Голдратт подверг этот подход обоснованной критике.

    > 5) баг-трекер позволяет планировать исправление дефектов. Например, вы решаете, что в ближайшие 3 дня фиксим все критические и важные дефекты (и вы видите их конкретный список), а минорные со следующей недели (и вы видите другой конкретный список). Или мы решаем выпустить продукт раньше, т.к. остались только минорные баги, заказчик с ними ознакомился и согласен принять, зато выйти на рынок пораньше.
    Есть такой подход. Но мы говорили о другом подходе. Когда правятся все дефекты.

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

    > с точки зрения концепции бережливой разработки программного обеспечения, очереди – это коллекторы непроизводительных затрат.
    Угу. Это аналог связанного капитала из мира материального производства. Смотри “Цель” (”та самая цель”) Голдратта. Голдратта в любом случае нужно почитать. Хотя бы пару книг.

    > Нельзя. Юнит тесты – это низкоуровневые тесты. Далеко не всегда их достаточно. Если ПО сложное, то отказ от высокоуровнего тестирования может привести к пропусканию критических багов в релиз.
    В примере именно сложное ПО. Сложность встроенного ПО весьма и весьма высока. Кроме того Юнит тесты могут быть весьма высокоуровневыми. Некоторые авторы называют их компонентными.

    >Книгу нашла, около 400 стр, на досуге почитаю. Если вы подскажете, в каком разделе раскрыта тема,
    ЕМНИЛ, она распределена по книге. Посыл, который я имел в виду: “Не бывает достаточно высокого уровня качества”. Главу, где разбирается функция Тагути читайте особенно внимательно.

    > речь о том, что если проблемы были и документировались, у вас будет больше материала для post mortem анализа, чем если дефекты все равно были, но не документировались.
    Не нужно их документировать. При обнаружении дефекта делается “останов линии” и устраняются причины дефекта. Но до такого подхода нужно проделать массу работы.

  8. Sergey Vysotsky написал:

    > Здесь зависимость должна быть обратная. Пост мортен анализ нужен для предотвращения дефектов, а не дефекты нужны для анализа. Не путайте причину и следствие.

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

    > Кроме того Юнит тесты могут быть весьма высокоуровневыми

    Не надо вносить путаницу в и без того весьма шаткую терминологию. http://www.salientblue.com/blog/?p=343

  9. SALar написал:

    > Это как стратегия работы с багами найденными в процессе регресионных тестов - можно чинить симптомы, а можно саму проблему.
    Переводя на более простой язык: “Изучая историю возникновения багов мы находим корневую причину и устраняем ее. Иными словами мы встраиваем качество в процесс. Такие исследование (пост мортен анализ) очень выгодно использовать для предотвращения дефектов”.

    И где у нас противоречие, коллега?

  10. Sergey Vysotsky написал:

    Вопрос простой - как работать с историей? Багтрекер по идее и есть эта история.

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.