Жизнь по задачам
#1
Отправлено 01 сентября 2009 - 11:02
Коллеги, подскажите по ситуации, пожалуйста.
Есть система таскменеджмента - Jira. В нее пишутся задачи, анализируются, разрешаются, etc. После того как разработчик поставил Resolved Fixed задача переходит в отдел тестирования. Если найдены какие-либо ошибки, то задача переоткрывается обратно на разработчика с описанием что и как. То есть все ошибки фигурируют внутри этой задачи, отдельной записи на баг не создается. Если проверка прошла и ошибок нет - задача отправляется дальше по этапам своего жизненного цикла.
При таком подходе можно отследить, что происходит с версией - N задач в разработке, М - в тестировании, Q - сделано. Но нельзя понять, сколько ошибок найдено по той или иной задаче. В принципе можно считать количество переоткрытий на каждую задачу, но это не самый легкий и удобный путь.
Собственно вопрос. Кто-нибудь еще живет по таким процессам? Как отслеживаются ошибки в таком случае? Или по каждой задаче идет отдельный поток ошибок дополнительно?
#2
Отправлено 01 сентября 2009 - 12:58
Купите наконец нормальную BTS! С иерархией объектов.
Стоит она - копейки. Все эти багзилы, мантисы и прочие джиры отлично подходят для гаражного кооператива. И в какой то момент становятся чемоданом без ручки. Бесплатен, но как неудобен!
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#3
Отправлено 01 сентября 2009 - 13:12
Совет принят)
#4
Отправлено 01 сентября 2009 - 18:32
Я, конечно, ничего не понял, но.В принципе можно считать количество переоткрытий на каждую задачу, но это не самый легкий и удобный путь.
Собственно вопрос. Кто-нибудь еще живет по таким процессам? Как отслеживаются ошибки в таком случае? Или по каждой задаче идет отдельный поток ошибок дополнительно?
У меня лично возникло ощущение, что джира очень своеобразна. Там, кажется, все-все-все можно настроить, но выглядит это очень противоестественно.
Во-вторых, переоткрытие задачи - тоже противоестественно.
С оптимистичной и очень ответственной точки зрения, пока задача не дотестирована и не доведена до ума, она должна быть открыта (и открытостью своей сигнализировать).
С реалистичной, при любом процессе у задачи есть две стадии - development ready и testing ready. Поэтому я бы ставил девелопмент-задачу в resolved, когда основная разработка закончена, заносил бы нормальные баги, пока они находятся, и ставил бы задачу в closed, когда открытых багов больше нет и приемочный тест пройден.
Разумно?
#5
Отправлено 01 сентября 2009 - 19:15
Ты видимо не работал с Jira, Сергей? Это платный и офигенно удобный продукт - после Борландовского еще Стартима - Jira самое лучшее решение для трекинга что я видел. Мы еще года 3-4 назад (на самой дорогой, правда, версии) построили полноценную систему управления проектом от получения требований через WBS и тренкинга ошибок. С кнопкой Relise даже :) Срастили с SVN для трекинга на код и с Confluence для автоматического построения документации и отчетов. Заметь - внутрь допиливать никто не лазил.Стоит она - копейки. Все эти багзилы, мантисы и прочие джиры отлично подходят для гаражного кооператива.
Редактор портала www.it4business.ru
#6
Отправлено 01 сентября 2009 - 19:17
Здесь маленькая поправка, которая починит процесс: баги заводим отдельно именно как баги и линкуем на таску. Если версия позвляет - можно делать баги сабтасками - пока сабтаск открыт - родитель не закроется. Пока есть не закрытый таск - не релизится версия.Есть система таскменеджмента - Jira. В нее пишутся задачи, анализируются, разрешаются, etc. После того как разработчик поставил Resolved Fixed задача переходит в отдел тестирования. Если найдены какие-либо ошибки, то задача переоткрывается обратно на разработчика с описанием что и как. То есть все ошибки фигурируют внутри этой задачи, отдельной записи на баг не создается.
Редактор портала www.it4business.ru
#7
Отправлено 03 сентября 2009 - 11:38
Программистов вроде как все устраивает. Как можно подтолкнуть к таким изменениям и какие аргументы привести, чтобы доказать, что нужны отдельные записи для каждой ошибки?
#8
Отправлено 03 сентября 2009 - 15:12
ЗЫ Философский настрой генерирует вопросы вроде "А следует ли толкать?" и "А следует ли толкать того, кто толкает тебя?"
Software Testing Glossary - простыми словами о непростых словах.
#9
Отправлено 03 сентября 2009 - 18:13
А можно теперь немного философии.
Как можно подтолкнуть к таким изменениям и какие аргументы привести, чтобы доказать, что нужны отдельные записи для каждой ошибки?
Хочется добавить, отдельные внятные (понятные) записи по каждой ошибке, изменению.
Мне нужно подробное знание ошибок и исправлений, чтобы знать, где и какие связи глубже "смотреть и анализировать", а кому-то просто затем, чтобы проверить сделано ли :)
По части философии Вы сами легко справитесь, если представите, что у Вас самого спрашивают такого совета, что бы Вы мне посоветовали, чтобы я могла доказать, что нужны отдельные записи для каждой ошибки?
К каждому человеку свой подход найти нужно.
С уважением, Vita
... you can learn from that too
#10
Отправлено 03 сентября 2009 - 18:25
Количество ошибок и оценки времени на их исправление помогают предсказать время завершения работ. Не подойдет?Программистов вроде как все устраивает. Как можно подтолкнуть к таким изменениям и какие аргументы привести, чтобы доказать, что нужны отдельные записи для каждой ошибки?
#11
Отправлено 04 сентября 2009 - 04:54
Что-то я не понял -- а кого не устраивает существующая ситуация? И почему? Просто потому, что "нельзя понять, сколько ошибок найдено по той или иной задаче"?А можно теперь немного философии.
Программистов вроде как все устраивает. Как можно подтолкнуть к таким изменениям и какие аргументы привести, чтобы доказать, что нужны отдельные записи для каждой ошибки?
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#12
Отправлено 04 сентября 2009 - 09:57
Не устраивает вышестоящее руководство, да. Хочется больше информации, чем просто количество переоткрытий на задачу.Что-то я не понял -- а кого не устраивает существующая ситуация? И почему? Просто потому, что "нельзя понять, сколько ошибок найдено по той или иной задаче"?
#13
Отправлено 04 сентября 2009 - 14:42
Переоткрытый тикет не позволяет оценить:
- количество проблем
- их северити
- время, требуемое на фикс
- когда баг был внесен и т.п.
Даже если стоит цель пофиксить все найденные баги (включая пожелания, что кнопочка должна быть зеленой, а не серой), эта информация позволит лучше контролировать ход проекта.
А можно теперь немного философии.
Программистов вроде как все устраивает. Как можно подтолкнуть к таким изменениям и какие аргументы привести, чтобы доказать, что нужны отдельные записи для каждой ошибки?
#14
Отправлено 12 февраля 2010 - 15:50
Хм, если не устраивает начальство, то все делается через административные рычаги.Не устраивает вышестоящее руководство, да. Хочется больше информации, чем просто количество переоткрытий на задачу.Что-то я не понял -- а кого не устраивает существующая ситуация? И почему? Просто потому, что "нельзя понять, сколько ошибок найдено по той или иной задаче"?
Пишется письмо, процедура или устно (все зависит от развития компании) с содержанием:
С этого момента мы живем по следующим правилам:
Правила....
И всем в ознакомление...
А через месяц желательно внутренний аудит для контроля выполнения правил игры с JIRA.
#15
Отправлено 14 июля 2010 - 10:32
Вот мы именно так и работаем. Я, как тестер захожу, смотрю. Баг нашла (2,3... сколько хочешь) - все отдельно зарепортила, прицепила к таску (ЮС в нашем случае), и таск переоткрыла. Программеру нотификейшен пришел про все. Он зашел, исправил все баги. Когда они все fixed он может вернуть статус resolved на таск. Как только он вернул статус резолвед - я опять нотификейшен получила. Зашла, проверила все прицепленные баги (у них тоже отдельно статус меняется), проверила опять функционал. Когда всё внутри проверено - меняю статус таска, что он проверен.Здесь маленькая поправка, которая починит процесс: баги заводим отдельно именно как баги и линкуем на таску. Если версия позвляет - можно делать баги сабтасками - пока сабтаск открыт - родитель не закроется. Пока есть не закрытый таск - не релизится версия.Есть система таскменеджмента - Jira. В нее пишутся задачи, анализируются, разрешаются, etc. После того как разработчик поставил Resolved Fixed задача переходит в отдел тестирования. Если найдены какие-либо ошибки, то задача переоткрывается обратно на разработчика с описанием что и как. То есть все ошибки фигурируют внутри этой задачи, отдельной записи на баг не создается.
Трекается все туда и обратно включая имя тестера, который все проверял (могут быть и разные тестеры).
ЗЫ: работаем с Мантисом. Хотя ИМХО большого значения это не имеет. Главное всем договориться.
#16
Отправлено 08 ноября 2011 - 06:15
#17
Отправлено 27 декабря 2011 - 05:43
#18
Отправлено 27 декабря 2011 - 07:55
На некоторых проектах пришли к выделенным багам, которые линкуются к задачам. На некоторых осталось как есть.
#19
Отправлено 24 декабря 2013 - 07:23
#20
Отправлено 24 декабря 2013 - 09:21
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных