А без вас разработка сама не решит что делать с задачей? Дефекты она видит
Size: a a a
2021 April 16
Если обязательно нужен канбан - то тут, да, надо подумать
A
У нас есть критерии можно ли релизить сторю. Если блокер для стори то сторя возвращается в девелопмент.
Если не блокер - то заводятся баги на сторю, она закрывается, баги чинятся. Но это типа не по канбану.
Или можно скрыть за фичефлагом, релизить скрытой и доделывать потом.
Если не блокер - то заводятся баги на сторю, она закрывается, баги чинятся. Но это типа не по канбану.
Или можно скрыть за фичефлагом, релизить скрытой и доделывать потом.
A
Ну у нас нет "когда хочешь") четкий workflow
M
Смотри. Тут речь не про "релизить". Вот есть, скажем, пять критикал мест для релиза. Пока тестируете - нашли косяк в одном. Но области с потенциальными четвёртым и пятым критом пока вообще не тестировались.
Сначала тестировать все области - и потом в девелопмент, или сразу вернуть?
Сначала тестировать все области - и потом в девелопмент, или сразу вернуть?
Насчёт "когда хочешь" - этого я не понял. Есть условные сроки для для проведения тестирования сборки. Есть багтркер. Когда передают - тестишь и заводишь баги. Разработка видит баги и принимает сама (почти) решение о целесообразности переключаться на задачу по доработке/правке багов и выкату новой сборке. Это зависит от серьезности багов, времени, доступного для тестирования сборки
Так что я делаю не так?
OS
Нашли косяк - задокументировали, отправили, глядишь, разработка быстрее пофиксит, чем ты дойдёшь до второго возможно критичного места.
A
Нашел баг-завел, тестируете дальше.
Дальше есть договоренности. К примеру что баги с текущих сторей имеют выше приоритет. Так что скорее всего пока вы продолжаете р тестируете ранее заведеные баги чинят. Цель - как можно более безбажная сторя
Дальше есть договоренности. К примеру что баги с текущих сторей имеют выше приоритет. Так что скорее всего пока вы продолжаете р тестируете ранее заведеные баги чинят. Цель - как можно более безбажная сторя
За временем особо следить не нужно. Речь же об одной команде - все по определению в курсе что и когда (ориентировочно). Митинги никто не отменял
Тестировщик в 90% случаев серьезность/критичность дефекта определяет правильно. Так что и за этим следить особо не надо. Дальше разработка (в коммуникации с ...) решает на какую задачу кого переключить
A
Плюс у нас для каждой фиче свой чат создается. Где PM, QA, Dev. И там принято говорить про проблемы и думать что с ними делать.
В общем не бывает у нас такого что dev не знает про баги на своих новых фичах
В общем не бывает у нас такого что dev не знает про баги на своих новых фичах
Не сталкивался с проблемой. Думаю, такое можно решить на уровне обычных переговоров, выстраивая процесс