Участники:
— программисты. У каждого свои проекты, у каждого проекта один программист
— тестеры. Не закреплены за проектами, делают то, что надо сейчас
— начальник тестеров. Назначает им задания
Сейчас процесс примерно такой:
1. Программист реализует запросы
2. Когда будет исправлена серьезная ошибка \ реализована важная функция, программист собирает очередную версию и запускает ее на тестирование
3. Начальство выбирает подходящего тестера
4. Тестер проверяет функциональность, возвращает версию на доработку. Программист дорабатывает, возвращает тестеру. И т.д. до победного
5. Начальство утверждает или возвращает на тестирование
В jire получилось вот так.
Ошибка:
Задание тестеру
Предполагаю, что программист будет связывать ошибки с заданием тестеру. Тогда тестер, открыв задание, увидит все запросы, которые ему надо проверить.
В jire я делаю первые шаги, хотелось бы услышать вашу критику и предложения. Спасибо!
Здравствуйте, enji, Вы писали:
E>В jire получилось вот так. E>Ошибка: E>
1. Если есть замечания по фиксу, то что делать?
2. "Назначен" разве может быть независимым статусом?
3. Если ошибка не воспроизводится, то что?
4. Если ошибка оказалась не ошибкой, то что?
5. Если решили отложить фикс, то что?
Здравствуйте, enji, Вы писали:
E>Сейчас процесс примерно такой: E>1. Программист реализует запросы E>2. Когда будет исправлена серьезная ошибка \ реализована важная функция, программист собирает очередную версию и запускает ее на тестирование E>3. Начальство выбирает подходящего тестера E>4. Тестер проверяет функциональность, возвращает версию на доработку. Программист дорабатывает, возвращает тестеру. И т.д. до победного E>5. Начальство утверждает или возвращает на тестирование
Мне кажется, что у Вас неправильно построен сам процесс.
Мы делаем так — версия планируется заранее, например, еженедельно, если это сопровождение/развитие.
Реквесты порождают одну или несколько задач программистам. Если это что-то большое или важное — подзадачей ставится задача тестеру, но это исключение.
Правило — последняя задача в данной версии -на тестера, тестирование ВЕРСИИ. В результате тестирования на программиста вешается одна задача со списком багов (если он у Вас один на проекте) и задача повторного тестирования. И так 15 раз подряд
Разница в подходах — программист выполняя следующую задачу может что-то испортить в функционале предыдущей, а так тестер головой отвечает, что Заказчику будет отправлена работоспособная версия.
Здравствуйте, A_N_M, Вы писали:
E>>Сейчас процесс примерно такой: E>>1. Программист реализует запросы E>>2. Когда будет исправлена серьезная ошибка \ реализована важная функция, программист собирает очередную версию и запускает ее на тестирование E>>3. Начальство выбирает подходящего тестера E>>4. Тестер проверяет функциональность, возвращает версию на доработку. Программист дорабатывает, возвращает тестеру. И т.д. до победного E>>5. Начальство утверждает или возвращает на тестирование
A_N>Мне кажется, что у Вас неправильно построен сам процесс. A_N>Мы делаем так — версия планируется заранее, например, еженедельно, если это сопровождение/развитие. A_N>Реквесты порождают одну или несколько задач программистам. Если это что-то большое или важное — подзадачей ставится задача тестеру, но это исключение. A_N>Правило — последняя задача в данной версии -на тестера, тестирование ВЕРСИИ. В результате тестирования на программиста вешается одна задача со списком багов (если он у Вас один на проекте) и задача повторного тестирования. И так 15 раз подряд
Пока не увидел особой разницы. У вас тестер видит задачу на тестирование и тестирует все баги этой версии (если я вас правильно понял), я же планирую связывать связывать их друг с другом. МОжет быть ваш способ и удобнее, надо пробовать.
Одна задача со списком багов- насколько это правильно? У нас сейчас примерно такая система, я хотел бы от нее уйти на плоский список багов —
1. Сложно найти баг в случае рецидива
2. К багу обычно крепятся логи, скриншоты и т.д.
С другой стороны, отдельный тикет на каждый баг — возможно неудобно тестеру?
A_N>Разница в подходах — программист выполняя следующую задачу может что-то испортить в функционале предыдущей, а так тестер головой отвечает, что Заказчику будет отправлена работоспособная версия.
ну а как вы от этого застрахуетесь? Все держится на внимательности программиста, который, если видит. что что-то может сломаться, говорит тестеру, что нужна перепроверка. Плюс регрессивные тесты
Здравствуйте, Lloyd, Вы писали:
L>1. Если есть замечания по фиксу, то что делать?
Я думаю, запрос "Задание на тестирование" вернется программисту целиком со всеми прикрепленными к нему ошибками. Дело в том, что обычно тикеты от программиста к тестеру и обратно ходят пачками, не хотелось бы менять статусы по отдельности.
А вот после завершения тестирования все не пофиксенное наверное надо вернуть в "открытые"
L>2. "Назначен" разве может быть независимым статусом?
Неудачное название видимо. "В работе" может лучше подойдет.
L>3. Если ошибка не воспроизводится, то что?
А как лучше сделать? Я вижу два варианта
— закрыть с резолюциями "Не воспроизводится"
— завести отдельный статус "Ожидает доп информации"
L>4. Если ошибка оказалась не ошибкой, то что?
По видимому программист закроет ее с резолюцией "Не ошибка"
L>5. Если решили отложить фикс, то что?
Фикс вернется в "Открыт"
Здравствуйте, enji, Вы писали:
E>Пока не увидел особой разницы. У вас тестер видит задачу на тестирование и тестирует все баги этой версии (если я вас правильно понял),
я же планирую связывать связывать их друг с другом. МОжет быть ваш способ и удобнее, надо пробовать.
E>Одна задача со списком багов- насколько это правильно? У нас сейчас примерно такая система, я хотел бы от нее уйти на плоский список багов — E>1. Сложно найти баг в случае рецидива E>2. К багу обычно крепятся логи, скриншоты и т.д.
E>С другой стороны, отдельный тикет на каждый баг — возможно неудобно тестеру?
A_N>>Разница в подходах — программист выполняя следующую задачу может что-то испортить в функционале предыдущей, а так тестер головой отвечает, что Заказчику будет отправлена работоспособная версия.
E>ну а как вы от этого застрахуетесь? Все держится на внимательности программиста, который, если видит. что что-то может сломаться, говорит тестеру, что нужна перепроверка. Плюс регрессивные тесты
Нет, на внимательности программиста ничего не держится.
1. Выполнив все задачи версии он (у нас тимлид) ее отчуждает — ветка на CVS.
2. Тестер к этому моменту уже создал/изменил тест-кейсы. Это он может сделать, поскольку видит все задачи к версии.
3. Тестер прогоняет набор тест кейсов и либо фиксирует ошибки, либо дает добро на отгрузку.
4. Если есть ошибки, программист их исправляет, work log в тех же задачах или, если мелочь и разрешено, в новой задаче. Правки делаются в ветке версии и, если надо, потом (после сдачи версии) сливается с транком
5. Идем к п.3. до тех пор пока тестер не принимает версию.
6. Если ЗАказчик нашел ошибки в версии, обязательно корректируются тест-кейсы.
7. Две метрики — сколько ошибок тестер нашел в работе программиста, включая повторы п.3-4, вторая сколько ошибок нашел в отгруженной версии.
Повторяемость ошибок — в привязке к тест-кейсам.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, enji, Вы писали:
G>Картинок не видно. Говорит not found.
G>Для оценки процесса нужны картинки состояний и переходов.
Для тестера. "Ожидает решения" это что за статус?
Для программиста: переход из "реализован" в Open — в какой ситуации делается, и что с такой задачей будет происходить дальше?
По статусам.
1)Их надо сделать более описательными. Например:
Open -> В очереди.
Релизован -> "На проверке"
2) Надо избежать дублирования аналогичных статусов в разных воркфлоу. Нечего плодить статусы и компостировать людям мозг. То есть:
"В очереди" — должно быть одинаковым состоянием и у программиста, и у тестера. Смысл статуса — задача запланирована к исполнению, но к ней еще не приступили.
"В работе" — исполнитель приступил, и выполняет работу. То есть, "у тестера" — это "в работе", тестирует он. А то, что он именно тестирует — следует их типа задачи, "тестирование".
Для того, чтобы обозначить, что работа по какой-либо причине не может продолжаться, так же заводится общий статус "Ожидает", и в него делается петля из статуса "в работе". Для задачи тестера — тестер ждет программиста, пока он не исправит ошибки. Программист, что характерно, также может кого-нить "ожидать", например, требовать уточнения постановки задачи.
Принимая это во внимание, цикл задачи тестирование такой:
Новый -> В очереди -> В работе -> Закрыт
И петля на ожидание: В работе <-> Ожидает
Второстепенные переходы я не рисую.
Новый — задача создана, и ни на кого не назначена.
В очереди — задаче назначен исполнитель, и она поставлена в его очередь работ (т.е. ее надо делать).
В работе — исполнитель приступил.
Ожидает — он не может продолжать, ждет кого-то или чего-то.
Закрыт — он завершил работу.
Это элементарный цикл работы без проверки результата, являющийся основой более сложных процессов.
Для программиста:
Новый -> В очереди -> В работе <-> На проверке -> Закрыт
И петля на ожидание: В работе <-> Ожидает
Все то же самое. Существенное отличие, как мы видим, только в наличии специального статуса ожидания, являющегося обязательным этапом работ. Еще раз, второстепенный переходы я не рисую, только главный поток переходов.
Данные варианты я привел только для того, чтобы проиллюстрировать принцип, по которому строятся воркфлоу.
Если следовать приведенным рекомендациям, все будет сильно проще, и станет очевидным, что циклы воркфлоу для разных специальностей не отличаются большим разнообразием. В них очень много общего.
Предлагаю все переделать, и назвать с того, чтобы назвать статусы правильно. То есть — поднять уровень абстракции, и максимально их переиспользовать. И для каждого статуса предельно четко расписать признаки ситуации. Сразу все на свои места встанет.
Спасибо за развернутый ответ!
G>Для тестера. "Ожидает решения" это что за статус?
Начальство после тестирования или утверждает версию ПО или заворачивает на доработку \ дотестирование.
G>"В очереди" — должно быть одинаковым состоянием и у программиста, и у тестера. Смысл статуса — задача запланирована к исполнению, но к ней еще не приступили.
У тестера в каждый момент обычно немного заданий, вводить для него отдельное состояние "в очереди" наверное нет смысла.
G>Предлагаю все переделать, и назвать с того, чтобы назвать статусы правильно. То есть — поднять уровень абстракции, и максимально их переиспользовать. И для каждого статуса предельно четко расписать признаки ситуации. Сразу все на свои места встанет.
В результате получилось вот так:
Баг/улучшение/новая возможность
Задача тестеру
И еще вопрос — как лучше "прикрепить" баги к заданию на тестирование?
Я пытался сделать через связь "на тестировании", однако получается не слишком хорошо — в теле задачи на тестирование видны только номера и названия багов, и не виден статус. Кроме того, при создании нового задания на тестирование неудобно привязывать баги.
Пока остановился на поле "исправлено в версии". Однако при этом тестер должен сам создавать себе фильтр по всем незакрытым багам, исправленным в этой версии.
Здравствуйте, A_N_M, Вы писали:
E>>ну а как вы от этого застрахуетесь? Все держится на внимательности программиста, который, если видит. что что-то может сломаться, говорит тестеру, что нужна перепроверка. Плюс регрессивные тесты
A_N>Нет, на внимательности программиста ничего не держится. A_N>1. Выполнив все задачи версии он (у нас тимлид) ее отчуждает — ветка на CVS. A_N>2. Тестер к этому моменту уже создал/изменил тест-кейсы. Это он может сделать, поскольку видит все задачи к версии. A_N>3. Тестер прогоняет набор тест кейсов и либо фиксирует ошибки, либо дает добро на отгрузку. A_N>4. Если есть ошибки, программист их исправляет, work log в тех же задачах или, если мелочь и разрешено, в новой задаче. Правки делаются в ветке версии и, если надо, потом (после сдачи версии) сливается с транком A_N>5. Идем к п.3. до тех пор пока тестер не принимает версию. A_N>6. Если ЗАказчик нашел ошибки в версии, обязательно корректируются тест-кейсы. A_N>7. Две метрики — сколько ошибок тестер нашел в работе программиста, включая повторы п.3-4, вторая сколько ошибок нашел в отгруженной версии. A_N>Повторяемость ошибок — в привязке к тест-кейсам.
Как я понимаю, для этого требуются автоматические тесты. Мы пока до них не доросли, к сожалению. Однако даже в этом случае все упирается в то, не сломалось ли при исправлении что-то такое, что пока не покрывается тестами...
Здравствуйте, enji, Вы писали:
G>>Для тестера. "Ожидает решения" это что за статус? E>Начальство после тестирования или утверждает версию ПО или заворачивает на доработку \ дотестирование.
Что ж, тогда еще проще. Тогда получается, что циклы задач тестирования и разработки полностью совпадают. И там и там есть шаг проверки.
G>>"В очереди" — должно быть одинаковым состоянием и у программиста, и у тестера. Смысл статуса — задача запланирована к исполнению, но к ней еще не приступили. E>У тестера в каждый момент обычно немного заданий, вводить для него отдельное состояние "в очереди" наверное нет смысла.
Количество задач в очереди у исполнителя здесь определяющим не является. Ибо — это количество явление преходящее, сегодня их мало, а завтра — случился пик, а мы даже понять не сможем, сколько заданий в работе (неудобно будет всем, в первую очередь исполнителю).
С другой стороны, переход из "в очереди" в "в работе" делается одним нажатием (совсем не сложно), и в этот момент заинтересованные лица могут получить почтовое уведомление. Когда сотрудник приступил к заданию — это важно. Также важно отличать то, что у него в очереди, от того, что в работе. Почему так? Например, я собираюсь в отпуск. В этот момент я могу набить сотрудникам очередь задач так, чтобы их хватило, скажем, на неделю.
Для этого (и не только для этого, причин много) необходимо уметь отличать те задания, к которым уже приступили, от тех, которые стоят в плане.
G>>Предлагаю все переделать, и назвать с того, чтобы назвать статусы правильно. То есть — поднять уровень абстракции, и максимально их переиспользовать. И для каждого статуса предельно четко расписать признаки ситуации. Сразу все на свои места встанет.
E>В результате получилось вот так:
E>Баг/улучшение/новая возможность E>
E>
E>Задача тестеру E>
E>
E>И еще вопрос — как лучше "прикрепить" баги к заданию на тестирование?
Использовать issue links, либо подзадачи. Первое позволяет связать несколько программерских задач с одной заявкой на тестирование, второе — нет.
Третий вариант — не парить мозг созданием других задач, и отправлять на тестирование саму задачу по разработке. Это самый простой и легковесный вариант, не всегда канает, естественно. Я всегда предпочитаю его подзадачам, исключением является ситуация, когда одно и то же должны несколько человек протестить (тогда остаются только подзадачи).
E>Я пытался сделать через связь "на тестировании", однако получается не слишком хорошо — в теле задачи на тестирование видны только номера и названия багов, и не виден статус.
Во-первых, все не так плохо. Как только задача закрывается — она зачеркивается.
Во-вторых, надо обязательно настроить почтовые уведомления, так, чтобы программист получал сообщения об ошибках.
В-третьих, надо завести кастомное поле "Зависит от", в статусе "Ожидает", и заставлять его заполнять на переходе. При выходе из ожидания автоматически его стирать.
В этом случае, можно настроить программисту фильтр, в котором он будет видеть все задания, которые от него зависят. А не только по одной задаче.
Из разных фильтров надо собрать дашборд (это то, чего нет в разных редмайнах). И все будет просто отлично.
E>Кроме того, при создании нового задания на тестирование неудобно привязывать баги.
Все не так плохо. Там поиск по номеру и названию при связывании. Начни печатать номер или слово из названия, выпадет список.
Хотя, именно поэтому я стараюсь избегать разных задач-подзадач, по возможности отражая проверки непосредственно в воркфлоу заданий.
Уж для проверки того, что дефект исправлен, точно не надо никаких отдельных задач на тестирование создавать.
Здравствуйте, enji, Вы писали:
E>Баг/улучшение/новая возможность E>
Очень хорошо. Все просто и симпатично — практически, как мои воркфлоу .
Остались разве что мелочи.
1) Обязательно сделай возможность переоткрыть задачу из закрытого состояния. Рано или поздно понадобится, а пока — люди не будут боятся закрывать задания со стремными резолюциями — вроде "не воспроизводится". Воспроизведется — переоткроете, че боятся-то. А ведь боятся.
2) Из "нового" можно сделать еще один переход в "В очереди", с названием "забрать себе". В нем — автоназначение на текущего пользователя. Это удобно для обработки дефектов при работе с общей очередью и дежурными.
Да, и я бы рекомендовал для начала унифицировать форкфлоу на тестера и программиста (т.е. взять пока один). Вырезать лишние состояния — это нормально, так можно делать, но лучше это делать по показаниям. Потом соптимизируешь — сначала настрой один воркфлоу, и отладь его в работе.
Здравствуйте, Gaperton, Вы писали:
G>Третий вариант — не парить мозг созданием других задач, и отправлять на тестирование саму задачу по разработке. Это самый простой и легковесный вариант, не всегда канает, естественно. Я всегда предпочитаю его подзадачам, исключением является ситуация, когда одно и то же должны несколько человек протестить (тогда остаются только подзадачи).
С этим есть проблемы:
а) Обычно программист выполняет несколько запросов, создает версию, отправляет ее тестеру с указаниями, на что обратить внимание при тестировании. Тестер тестит, пишет замечания, возвращает программисту. Тот правит, собирает выкладывает обновление версии. Т.е. хотелось бы знать, у кого сейчас "мяч" — кто держит — тестер или программист.
б) начальству удобно назначать тестера один раз — в одной задаче на тестирование. Опять же удобно видеть, что счас тестируются скажем 5 версий, а не 1050 багов\фич
в) у нас из одной кодовой базы растут разные программы. Т.е. одна и та же ошибка может фигурировать в разных заданиях тестеру, на разные версии разных программ. Если завести у бага кастомное поле "тестер", то в нем останется только последний тестер, а остальная инфа будет доступна только из перечня изменений.
Если же делать через связи, то у бага видны задания тестеру, по которым он проходил, а у задания — баги.
E>>Я пытался сделать через связь "на тестировании", однако получается не слишком хорошо — в теле задачи на тестирование видны только номера и названия багов, и не виден статус.
G>Во-первых, все не так плохо. Как только задача закрывается — она зачеркивается.
Зачеркиваются задачи с резолюцией, а не закрытые. Т.е. программист поправил баг, у него резолюция "исправлено", хотя баг еще надо тестить. Тот факт, что баг протестирован, т.е. имеет статус "закрыт" не отображается.
В принципе если жира у нас приживется, можно будет и плагин написать для кастомного отображения. Пока же можно обойтись полем "исправлено в версиях"
Здравствуйте, Gaperton, Вы писали:
E>>Баг/улучшение/новая возможность E>>
G>Очень хорошо. Все просто и симпатично — практически, как мои воркфлоу .
G>1) Обязательно сделай возможность переоткрыть задачу из закрытого состояния. Рано или поздно понадобится, а пока — люди не будут боятся закрывать задания со стремными резолюциями — вроде "не воспроизводится". Воспроизведется — переоткроете, че боятся-то. А ведь боятся.
уже есть — переход 101 G>2) Из "нового" можно сделать еще один переход в "В очереди", с названием "забрать себе". В нем — автоназначение на текущего пользователя. Это удобно для обработки дефектов при работе с общей очередью и дежурными.
Да, стоит сделать
G>Да, и я бы рекомендовал для начала унифицировать форкфлоу на тестера и программиста (т.е. взять пока один). Вырезать лишние состояния — это нормально, так можно делать, но лучше это делать по показаниям. Потом соптимизируешь — сначала настрой один воркфлоу, и отладь его в работе.
Они похожи, но например переходы называются все же по разному. Хотя возможно стоит начать с одного, а как устаканится — скопировать и поменять
Здравствуйте, enji, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>Третий вариант — не парить мозг созданием других задач, и отправлять на тестирование саму задачу по разработке. Это самый простой и легковесный вариант, не всегда канает, естественно. Я всегда предпочитаю его подзадачам, исключением является ситуация, когда одно и то же должны несколько человек протестить (тогда остаются только подзадачи).
E>С этим есть проблемы:
E>а) Обычно программист выполняет несколько запросов, создает версию, отправляет ее тестеру с указаниями, на что обратить внимание при тестировании. Тестер тестит, пишет замечания, возвращает программисту. Тот правит, собирает выкладывает обновление версии. Т.е. хотелось бы знать, у кого сейчас "мяч" — кто держит — тестер или программист.
Тогда получается отдельная связанная задача для тестера, остальное не канает. Приведенной причины уже достаточно.
G>>Во-первых, все не так плохо. Как только задача закрывается — она зачеркивается. E>Зачеркиваются задачи с резолюцией, а не закрытые. Т.е. программист поправил баг, у него резолюция "исправлено", хотя баг еще надо тестить. Тот факт, что баг протестирован, т.е. имеет статус "закрыт" не отображается.
В JIRA факт наличия непустой резолюции и обозначает закрытые задачи. Я бы не стал присваивать задаче резолюцию, пока она не попадет в статус "Закрыта" (и никогда не присаиваю задачам резолюций, в статусах, из которых ожидается скорая движуха). Но тут уж хозяин барин.
E>В принципе если жира у нас приживется, можно будет и плагин написать для кастомного отображения. Пока же можно обойтись полем "исправлено в версиях"
Не лучший вариант, ИМХО, плодить версию на каждый билд.
Если нужно понятие билдов — то лучше поднять рядом Bamboo, он даст в JIRA билды, и привяжет к ним задачи.
Здравствуйте, Gaperton, Вы писали:
E>>Зачеркиваются задачи с резолюцией, а не закрытые. Т.е. программист поправил баг, у него резолюция "исправлено", хотя баг еще надо тестить. Тот факт, что баг протестирован, т.е. имеет статус "закрыт" не отображается.
G>В JIRA факт наличия непустой резолюции и обозначает закрытые задачи. Я бы не стал присваивать задаче резолюцию, пока она не попадет в статус "Закрыта" (и никогда не присаиваю задачам резолюций, в статусах, из которых ожидается скорая движуха). Но тут уж хозяин барин.
Гм, а как тогда сделать? Резолюцию задаче выносит программист, а затем утверждает тестер. Т.е. я полагал что при переходе "в работе" -> "на проверке" программист присваивает резолюцию. А при обратном переходе она снимается.
Например, тестер создал задачу. Программист посмотрел на нее и решил что это повтор. Он установил резолюцию "повтор" и вернул тестеру. Тот согласился и закрыл. Или не согласился, написал соответствующий коммент и вернул программисту
E>>В принципе если жира у нас приживется, можно будет и плагин написать для кастомного отображения. Пока же можно обойтись полем "исправлено в версиях"
G>Не лучший вариант, ИМХО, плодить версию на каждый билд. G>Если нужно понятие билдов — то лучше поднять рядом Bamboo, он даст в JIRA билды, и привяжет к ним задачи.
детализация по билдам пока наверное не нужна. Я имел в виду следующее — программист собрал версию 7 (ревизия СВН 1250) и отправил на тестирование. Тестер нашел 10 ошибок и указал, что они должны быть исправлены в версии 7. Программист их отработал. Затем он сделал очередной билд (скажем ревизия СВН 1260) и отдал его тестеру. Тот факт, что баги исправлены именно в ревизии СВН 1260 особо никого не интересует. Об этом можно написать в комменте к ошибке, а в комментарии СВН сослаться на номер задачи JIRA.
У тестера есть задание на тестирование версии 7 и настроен фильтр на все незакрытые задачи, исправленные в версии 7. Соответственно получив себе "задание на тестирование" он смотрит все незакрытые баги в этом фильтре, проверяет их и либо закрывает, либо возвращает программисту.
Здравствуйте, enji, Вы писали:
G>>В JIRA факт наличия непустой резолюции и обозначает закрытые задачи. Я бы не стал присваивать задаче резолюцию, пока она не попадет в статус "Закрыта" (и никогда не присаиваю задачам резолюций, в статусах, из которых ожидается скорая движуха). Но тут уж хозяин барин.
E>Гм, а как тогда сделать? Резолюцию задаче выносит программист, а затем утверждает тестер. Т.е. я полагал что при переходе "в работе" -> "на проверке" программист присваивает резолюцию. А при обратном переходе она снимается.
Резолюция должна ставится на переходе в состояние "закрыто". Для закрытия с резолюциями вроде won't fix делаются дополнительные переходы из тех состояний, откуда это возможно.
E>Например, тестер создал задачу. Программист посмотрел на нее и решил что это повтор. Он установил резолюцию "повтор" и вернул тестеру. Тот согласился и закрыл. Или не согласился, написал соответствующий коммент и вернул программисту.
Программист в такой ситуации берет, и закрывает задачу с резолюцией "дубликат", проставляя линк на ту задачу, которая дубликат. Если тестер не согласен — он ее переоткрывает.
E>У тестера есть задание на тестирование версии 7 и настроен фильтр на все незакрытые задачи, исправленные в версии 7. Соответственно получив себе "задание на тестирование" он смотрит все незакрытые баги в этом фильтре, проверяет их и либо закрывает, либо возвращает программисту.
В этом случае вообще непонятно, зачем тестерам нужны отдельные задачи. При такой схеме можно обойтись одним типом задачи — для программиста. Фильтр делается по состоянию "на проверке", и по привязке к версии. Возможно дополнительно ввести custom field Тестер, чтобы дополнительно фильтровать по нему.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, enji, Вы писали:
G>>>В JIRA факт наличия непустой резолюции и обозначает закрытые задачи. Я бы не стал присваивать задаче резолюцию, пока она не попадет в статус "Закрыта" (и никогда не присаиваю задачам резолюций, в статусах, из которых ожидается скорая движуха). Но тут уж хозяин барин.
E>>Например, тестер создал задачу. Программист посмотрел на нее и решил что это повтор. Он установил резолюцию "повтор" и вернул тестеру. Тот согласился и закрыл. Или не согласился, написал соответствующий коммент и вернул программисту.
G>Программист в такой ситуации берет, и закрывает задачу с резолюцией "дубликат", проставляя линк на ту задачу, которая дубликат. Если тестер не согласен — он ее переоткрывает.
Этот вариант мне не слишком нравится. В моем случае тестер фильтрует задачи по версии и статусу "На проверке" и видит все, что требует его внимания. При этом, по мере отработки, задачи из этого фильтра будут пропадать. В вашем же варианте тестер не увидит самостоятельно закрытые программистом задачи в каком-то общем списке или же фильтр усложнится.
С другой стороны, я немного покопался в жире, там очень многое привязано к тому, что "вынесена резолюция" = задача отработана. Все это менять не охота. Я думаю сделать кастомное поле "резолюция программиста", которое будет копироваться в резолюцию после утверждения тестером
E>>У тестера есть задание на тестирование версии 7 и настроен фильтр на все незакрытые задачи, исправленные в версии 7. Соответственно получив себе "задание на тестирование" он смотрит все незакрытые баги в этом фильтре, проверяет их и либо закрывает, либо возвращает программисту.
G>В этом случае вообще непонятно, зачем тестерам нужны отдельные задачи. При такой схеме можно обойтись одним типом задачи — для программиста. Фильтр делается по состоянию "на проверке", и по привязке к версии. Возможно дополнительно ввести custom field Тестер, чтобы дополнительно фильтровать по нему.
Чтобы:
а) начальство тестеров могло раскидать задания на тестирование разных версий между тестерами
б) можно было понять, какой тестер тестировал запрос — кастомное поле "Тестер" этой задачи не решает — один и тот же запрос может тестироваться в составе нескольких версий
в) было видно, какие версии сейчас на тестировании
отвечает, что Заказчику будет отправлена работоспособная версия.
