Жизненный цикл (Workflow) задач

Жизненный цикл задачи — это то, по каким статусам она проходит от момента заведения до полного исправления, проверки и закрытия. В каждом баг-трекинге есть стандартный Workflow, но его всегда можно поменять под свои нужды. Рассмотрим типовые жизненные циклы

Open — Closed

Самый простой жизненный цикл содержит всего два состояния:

• Открыто (Open)
• Закрыто (Closed)

Как это выглядит в реальном мире:

• Тестировщик нашел баг, заводит задачу и вешает ее на разработчика. Задача находится в статусе Open
• Разработчик исправил баг и перевешивает на тестировщика для проверки — делает Assign to (назначить на), задача остается открытой (Open)
• Тестировщик проверяет исправление:
• Если все ок — закрывает, статус Closed
• Если не ок — снова вешает на разработчика, статус остается Open
• Повторить N раз, пока задача не будет закрыта

Схема 1. Open — Open — Close

Ладно, ладно! Разумеется, это не самый простой сценарий. Самый простой сценарий более топорный:

• Тестировщик нашел баг и повесил его на разработчика — задача в статусе Open
• Разработчик исправил и... Закрыл! Статус Closed

Схема 2. Open — Close

Но плох тот тестировщик, что не проверил свое детище: правда ли разработчик все исправил? Бывает такое, что в задаче описано несколько способов воспроизведения, а разработчик поправил только один. Или он сказал «Исправлено», а баг продолжает воспроизводится: что-то недоправил, разработчик ведь не тестировщик, проверить нормально не может.

Если все так и оставить, плохо будет всей команде — разработчик думает, что исправил баг, тестировщик слепо верит, в итоге баг уезжает в продакшен к заказчикам. Плохо? Да! Раз такое случится, два, потом тестировщик все же начнет следить за своими задачами:

• Тестировщик нашел баг и повесил его на разработчика — задача в статусе Open
• Разработчик исправил и... Закрыл! Статус Closed
• Тестировщик проверяет исправление:
• Если все ок — ничего не делает, статус остается Closed
• Если не ок — переоткрывает, вешает на разработчика, статус Open (или Reopen)
• Повторить N раз, пока тестировщик не перестанет переоткрывать задачу

Схема 3. Open — Close — Reopen

Но такой процесс неудобен.

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

Во-вторых, даже если разработчика устраивает переоткрытие, тестировщик может продолбать задачу. Как отличить закрытую, которую надо проверить, от просто закрытой? Как настроить фильтр в баг-трекере, чтобы видеть, что ему надо сделать? Это неудобно.

И в итоге возвращаемся к схеме 1, «Задача открыта, пока не исправлена и проверена. Просто меняет исполнителя: либо разработчик чинит, либо тестировщик проверяет».

Open — Resolve — Closed

Мы добавили в JIRA дополнительное поле «Закрывающий» — тот, кто будет тестировать задачу. И отдельный статус Resolve (проблема решена). Теперь можно легко настраивать фильтры, так как каждый статус «говорящий»:

• Open — задача на разработчике, она или новая, или переоткрыта;
• Resolve — задача сделана, но ожидает тестирования;
• Close — все супер, исправили и проверили!

Схема 4. Open — Resolve — Close

А дополнительное поле помогает при оценке задач. Когда мы берем задачу в релиз, нужно оценить, сколько ресурсов на нее выделить. И если у нас есть только «Исполнитель», который меняется с разработчика на тестировщика, то как запомнить выделенные 10 дней — это все время разработчика? Или обоих? А сколько тогда там времени разработчика, сколько тестировщика?

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

Схема со всеми участниками

Даже если у нас всего три основные состояния:

• Open — в разработчке
• Resolve / Testing — в тестировании
• Close — закрыта

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

• Тестировщик нашел баг, поставил на старшего разработчика
• Старший разработчик решает, кто будет исправлять и уже он назначает исполнителя
• А дальше все как обычно

Схема 5. Со старшим разработчиком

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

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

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

Схема 6. С тест-менеджером

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

И, конечно, не всегда тестировщик может сформулировать ожидаемый результат. Как вообще планировалось, чтобы работало? Тогда в схему добавляется аналитик — сначала задачу вешают на него, а он уже определяет требования для разработки.

Схема 7. С аналитиком

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

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

Если вы работаете на разных проектах, то можете участвовать в разных схемах:

• В проекте 1 будет самая сложная схема, с тест-менеджером, аналитиком и старшим разработчиком.
• В проекте 2 схема сама простая, Open или Close.
• В проекте 3 вообще нет баг-трекера и вы сообщаете о багах устно или пишете об этом в скайп. Это тоже допустимо, хотя и теряются все преимущества спец инструментов.

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

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

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