Размышления
ФИКСАЦИЯ ДЕФЕКТОВ - ЗАЧЕМ и КОМУ ЭТО НАДО?
Я всегда заводила все дефекты, но в последнее время всё чаще сталкиваюсь с ситуациями, когда практика фиксации дефектов отсутствует в масштабах организации.
Не скажу, что ранее я никогда с подобным не сталкивалась. Сталкивалась, в основном в стартапах из 10-15 человек, которые разрабатывали небольшие продукты (мобильные, десктопные, веб). Тогда я консультировала их в части обеспечения качества, и на вопрос: "Почему вы не фиксируете дефекты?" получала ответ из разряда: "А зачем, если мы сразу их исправляем или принимаем решение, что дефект никогда не будет исправляться?". Ну что ж, когда бизнес сидит в одной комнате с разработкой и может себе позволить принимать решение моментально по поводу каждого дефекта, а главная метрика - соотношение финансовых затрат и прибыли, то аргумент звучит вполне обоснованно. При этом, кстати, не могу сказать, что продукты всех этих стартапов пользовались популярностью... Пока они были бесплатными и доход компаниям шел от рекламы, отзывы в интернете были вполне неплохие (не отличные, а именно вполне неплохие) - люди готовы были терпеть рекламу и не особо высокое качество. Зато бесплатно, как говорится :) Ситуация изменилась, когда отдельные продукты стали платными. Положительные отзывы пропали с просторов интернета совсем. Не знаю как сейчас у ребят дела, но что было, то было...
Так вот теперь представим, что у вас не стартап из 10-15 человек, а крупная организация из 1000+ человек, когда один продукт разрабатывают команды по 20-50 человек. И заказчик либо внешний, либо есть один владелец продукта на всю эту ораву разработчиков. И в такой ситуации команды живут в парадигме либо дефекты фиксировать не надо вообще, либо фиксировать только избранные (например, регрессионные), либо создавать одну задачу на 10-20 дефектов, т.е. на все, что "под руку попались" в какой-то период тестирования.
Стоит сказать, что под фиксацией дефектов я имею ввиду фиксацию:
1) в системе управления дефектами;
2) фиксацию 1 к 1, то есть 1 задача = 1 дефект.
И так как я все чаще сталкиваюсь с описанными выше ситуациями, я решила в статье максимально полно обосновать посыл, что фиксировать дефекты полезно и необходимо.
Не скажу, что ранее я никогда с подобным не сталкивалась. Сталкивалась, в основном в стартапах из 10-15 человек, которые разрабатывали небольшие продукты (мобильные, десктопные, веб). Тогда я консультировала их в части обеспечения качества, и на вопрос: "Почему вы не фиксируете дефекты?" получала ответ из разряда: "А зачем, если мы сразу их исправляем или принимаем решение, что дефект никогда не будет исправляться?". Ну что ж, когда бизнес сидит в одной комнате с разработкой и может себе позволить принимать решение моментально по поводу каждого дефекта, а главная метрика - соотношение финансовых затрат и прибыли, то аргумент звучит вполне обоснованно. При этом, кстати, не могу сказать, что продукты всех этих стартапов пользовались популярностью... Пока они были бесплатными и доход компаниям шел от рекламы, отзывы в интернете были вполне неплохие (не отличные, а именно вполне неплохие) - люди готовы были терпеть рекламу и не особо высокое качество. Зато бесплатно, как говорится :) Ситуация изменилась, когда отдельные продукты стали платными. Положительные отзывы пропали с просторов интернета совсем. Не знаю как сейчас у ребят дела, но что было, то было...
Так вот теперь представим, что у вас не стартап из 10-15 человек, а крупная организация из 1000+ человек, когда один продукт разрабатывают команды по 20-50 человек. И заказчик либо внешний, либо есть один владелец продукта на всю эту ораву разработчиков. И в такой ситуации команды живут в парадигме либо дефекты фиксировать не надо вообще, либо фиксировать только избранные (например, регрессионные), либо создавать одну задачу на 10-20 дефектов, т.е. на все, что "под руку попались" в какой-то период тестирования.
Стоит сказать, что под фиксацией дефектов я имею ввиду фиксацию:
1) в системе управления дефектами;
2) фиксацию 1 к 1, то есть 1 задача = 1 дефект.
И так как я все чаще сталкиваюсь с описанными выше ситуациями, я решила в статье максимально полно обосновать посыл, что фиксировать дефекты полезно и необходимо.
Цель - зачем фиксировать дефекты
Цели бывают разные. Начиная с требований регуляторного органа, контрактных обязательств, и заканчивая желанием... повысить прозрачность, чтобы понимать что происходит, на что тратится время разработчиков и тестировщиков.
В общем-то, может подойти любая цель из списка ниже.
Благодаря фиксации дефектов можно закрыть следующие цели:
В общем-то, может подойти любая цель из списка ниже.
Благодаря фиксации дефектов можно закрыть следующие цели:
- Понимать уровень качества продукта и процесса:
- области продукта наиболее подверженные риску - плотность дефектов (defects density);
- эффективность тестирования - процент дефектов, дошедших до клиента и обнаруженных пользователями (escaped defects ratio);
- продуктивность процесса разработки - время простоя реализации задачи из-за дефектов;
- Обосновать сдвиг сроков в отдельных случаях;
- Повысить прозрачность текущих активностей - понимать над чем конкретно работает человек или почему "задача" подвисла в тестировании;
- Повышение уровня планирования - начиная с уровня завершения задачи, заканчивая планированием квартала/релиза;
- Повышение уровня понимания бизнеса и пользователей - на основании приоритетов дефектов;
- Ускорить процесс разработки и увеличить объем поставляемой функциональности - засчет приоритизации дефектов;
- Историчность - какие были обсуждения, почему дефект был приоритизирован именно так, почему был закрыт.
Основные аргументы против фиксации всех дефектов
УРОВЕНЬ ФИЗИОЛОГИЧЕСКИХ ПОТРЕБНОСТЕЙ
- "Это не Agile!"
- "Это будет занимать много времени. которого и так в большинстве случаев катастрофически не хватает на тестирование!"
- "Это замедлит весь цикл разработки! Пока дефект зафиксируешь, пока разработчик на него посмотрит..."
Прежде, чем приводить доводы о том, что данные аргументы - лишь лозунги, не имеющие под собой фундамента, я хочу рассмотреть некоторые причины сопротивления введению практики фиксации дефектов, ведь именно с сопротивлением я и сталкиваюсь от раза к разу. Итак, попробую проанализировать что может стоять "за спиной" сопротивленца? О чем чаще всего не говорят, что даже не все понимают. Для этой цели я воспользуюсь (банально) пирамидой Маслоу вместе с набором стремлений UnFix. Их я разбирала на встрече по мотивации.
Пойдем снизу вверх по пирамиде.
Единственное стремление на уровне физиологических потребностей, на которое, с моей точки зрения, может повлиять правило заведения всех дефектов - это стремление "отдых".
Я не спорю, и даже не собираюсь спорить с тем, что фиксация дефектов может занимать чуть больше времени, чем написать о нем в чате/комментарии к задаче. При этом для меня спорно что быстрее: зафиксировать дефект в системе управления дефектами или дойти до разработчика и рассказать/показать. При этом, со слов моих оппонентов это обычно звучит так, как будто вместо "меньше минуты сейчас" они будут тратить чуть ли ни по "10-30 минут на фиксацию дефектов", что не соответствует действительности.
Давайте прикинем на самом ли деле придется перерабатывать, сидеть ночами, без выходных лишь потому, что вместо личных чатов/комментариев/похода ногами к разработчику тестировщик будет фиксировать дефекты?
Для этого нужно прикинуть сколько раз в чате обсуждение дефекта затягивается на десятки минут, прерывается, потому что отвлекли/ушел на встречу один из участников беседы, а потом приходится вспоминать, обсуждать заново..
А сколько времени уходит на обсуждение в комментариях? Сколько раз разработчик приходит с уточнениями? В скольких случаях из 10 он не понимает в чем проблема?
Сколько времени тестировщик сидит/стоит рядом с разработчиком, ожидая, когда он допишет мысль/функцию, переключится на вопрос дефекта?
Думаю, даже если у вас нет такого опыта обсуждения дефектов, вы можете легко себе представить как это может выглядеть, ведь загрузка в IT компаниях плюс-минус одинакова, отвлечение есть в опыте у каждого. Уровень детализации, когда что-то пишется на коленке тоже легко представляем и не отличается от случая к случаю. И вы не сильно ошибетесь, если придете к выводу, что тратится уйма времени на подобные варианты коммуникации. Не "меньше минуты" уж точно. И даже не 1-2 минуты. Минимум 5, а максимум...
И вместо этого нужно заполнить шаблон дефекта в системе управления дефектами. Да, это занимает время. Не больше 2-х минут в среднем, на моем опыте. А я, к слову, 10 лет работала тестировщиком и все 10 лет создавала дефекты. И выглядит, как будто, время начинает экономиться у тестировщика уж точно, в случае, если он фиксирует дефекты, а не пишет в личку/комменты/идет ногами к разработчику. И, как будто, наоборот, есть все шансы, что времени на отдых станет больше, если начать фиксировать дефекты в системе управления дефектами.
На что на самом деле может уходить много времени - так это на локализацию дефекта, на выявление минимальных и полных условий его воспроизведения. Подробнее об этом...
Какова вероятность, что сложно локализуемый дефект (при этом он может вполне легко воспроизводиться) будет полностью описан в комментарии, и что разработчику не придется тратить время на локализацию, на попытки воспроизвести, найти связи и случаи воспроизведения? Предположу, что локализация в случае "быстренько черкануть" в личку/комментарий и тп будет описана, мягко говоря "не очень". И вот тут стоит вспомнить, что локализация - задача тестировщика, которая вполне может перекладываться на плечи разработчика в случае комментария/заметки. Отсюда так же могут рождаться и обсуждения, вопросы, уточнения, в общем, всё то, о чем я писала выше. И тратится не только время тестировщика, которое и должно тратиться на локализаицю, но еще и время разработчика.
И что теперь выглядит эффективнее, продуктивнее и быстрее? В каком случае у тестировщика и у разработчика больше шансов на заслуженный отдых?
Я не спорю, и даже не собираюсь спорить с тем, что фиксация дефектов может занимать чуть больше времени, чем написать о нем в чате/комментарии к задаче. При этом для меня спорно что быстрее: зафиксировать дефект в системе управления дефектами или дойти до разработчика и рассказать/показать. При этом, со слов моих оппонентов это обычно звучит так, как будто вместо "меньше минуты сейчас" они будут тратить чуть ли ни по "10-30 минут на фиксацию дефектов", что не соответствует действительности.
Давайте прикинем на самом ли деле придется перерабатывать, сидеть ночами, без выходных лишь потому, что вместо личных чатов/комментариев/похода ногами к разработчику тестировщик будет фиксировать дефекты?
Для этого нужно прикинуть сколько раз в чате обсуждение дефекта затягивается на десятки минут, прерывается, потому что отвлекли/ушел на встречу один из участников беседы, а потом приходится вспоминать, обсуждать заново..
А сколько времени уходит на обсуждение в комментариях? Сколько раз разработчик приходит с уточнениями? В скольких случаях из 10 он не понимает в чем проблема?
Сколько времени тестировщик сидит/стоит рядом с разработчиком, ожидая, когда он допишет мысль/функцию, переключится на вопрос дефекта?
Думаю, даже если у вас нет такого опыта обсуждения дефектов, вы можете легко себе представить как это может выглядеть, ведь загрузка в IT компаниях плюс-минус одинакова, отвлечение есть в опыте у каждого. Уровень детализации, когда что-то пишется на коленке тоже легко представляем и не отличается от случая к случаю. И вы не сильно ошибетесь, если придете к выводу, что тратится уйма времени на подобные варианты коммуникации. Не "меньше минуты" уж точно. И даже не 1-2 минуты. Минимум 5, а максимум...
И вместо этого нужно заполнить шаблон дефекта в системе управления дефектами. Да, это занимает время. Не больше 2-х минут в среднем, на моем опыте. А я, к слову, 10 лет работала тестировщиком и все 10 лет создавала дефекты. И выглядит, как будто, время начинает экономиться у тестировщика уж точно, в случае, если он фиксирует дефекты, а не пишет в личку/комменты/идет ногами к разработчику. И, как будто, наоборот, есть все шансы, что времени на отдых станет больше, если начать фиксировать дефекты в системе управления дефектами.
На что на самом деле может уходить много времени - так это на локализацию дефекта, на выявление минимальных и полных условий его воспроизведения. Подробнее об этом...
Какова вероятность, что сложно локализуемый дефект (при этом он может вполне легко воспроизводиться) будет полностью описан в комментарии, и что разработчику не придется тратить время на локализацию, на попытки воспроизвести, найти связи и случаи воспроизведения? Предположу, что локализация в случае "быстренько черкануть" в личку/комментарий и тп будет описана, мягко говоря "не очень". И вот тут стоит вспомнить, что локализация - задача тестировщика, которая вполне может перекладываться на плечи разработчика в случае комментария/заметки. Отсюда так же могут рождаться и обсуждения, вопросы, уточнения, в общем, всё то, о чем я писала выше. И тратится не только время тестировщика, которое и должно тратиться на локализаицю, но еще и время разработчика.
И что теперь выглядит эффективнее, продуктивнее и быстрее? В каком случае у тестировщика и у разработчика больше шансов на заслуженный отдых?
ОТДЫХ
Иметь возможность восстанавливать силы
Связаться со мной:
