Size: a a a

2021 April 16

‌‌‎Оо in QA Сибирь
А без вас разработка сама не решит что делать с задачей? Дефекты она видит
источник

M

Marina in QA Сибирь
Интересно. С таким не сталкивалась. Обычно разработка видит задачу, которая на неё назначена) и, честно говоря, мне это кажется логичным
источник

M

Marina in QA Сибирь
Как бы если задача на доске не на тебе, то грубо говоря ты за её движение вперёд и ответственности не несёшь
источник

‌‌‎Оо in QA Сибирь
Если обязательно нужен канбан - то тут, да, надо подумать
источник

A

Aleksander in QA Сибирь
У нас есть критерии можно ли релизить сторю. Если блокер для стори то сторя возвращается в девелопмент.
Если не блокер - то заводятся баги на сторю, она закрывается, баги чинятся. Но это типа не по канбану.
Или можно скрыть за фичефлагом, релизить скрытой и доделывать потом.
источник

M

Marina in QA Сибирь
Нет, мне теперь интересно, что это за процесс, когда ты когда хочешь протестировал, когда хочешь завёл баги, когда хочешь пофиксал х) я в таких не работала)
источник

A

Aleksander in QA Сибирь
Ну у нас нет "когда хочешь") четкий workflow
источник

M

Marina in QA Сибирь
Смотри. Тут речь не про "релизить". Вот есть, скажем, пять критикал мест для релиза. Пока тестируете - нашли косяк в одном. Но области с потенциальными четвёртым и пятым критом пока вообще не тестировались.
Сначала тестировать все области - и потом в девелопмент, или сразу вернуть?
источник

‌‌‎Оо in QA Сибирь
Насчёт "когда хочешь" - этого я не понял. Есть условные сроки для для проведения тестирования сборки. Есть багтркер. Когда передают - тестишь и заводишь баги. Разработка видит баги и принимает сама (почти) решение о целесообразности переключаться на задачу по доработке/правке багов и выкату новой сборке. Это зависит от серьезности багов, времени, доступного для тестирования сборки
источник

‌‌‎Оо in QA Сибирь
Так что я делаю не так?
источник

M

Marina in QA Сибирь
Почему не так-то? Нет никакого "не так" :) но, получается, разработка следит за серьёзностью багов и временем, доступным для тестирования?
источник

OS

Oksana Smovzh in QA Сибирь
Нашли косяк - задокументировали, отправили, глядишь, разработка быстрее пофиксит, чем ты дойдёшь до второго возможно критичного места.
источник

A

Aleksander in QA Сибирь
Нашел баг-завел, тестируете дальше.
Дальше есть договоренности. К примеру что баги с текущих сторей имеют выше приоритет. Так что скорее всего пока вы продолжаете р тестируете ранее заведеные баги чинят. Цель - как можно более безбажная сторя
источник

‌‌‎Оо in QA Сибирь
За временем особо следить не нужно. Речь же об одной команде - все по определению в курсе что и когда (ориентировочно). Митинги никто не отменял
источник

‌‌‎Оо in QA Сибирь
Тестировщик в 90% случаев серьезность/критичность дефекта определяет правильно. Так что и за этим следить особо не надо. Дальше разработка (в коммуникации с ...)  решает на какую задачу кого переключить
источник

M

Marina in QA Сибирь
@Qsusha тоже:
тогда если находится что-то, блокирующее дальнейшее тестирование - оно идёт по отдельному флоу?
+ если есть необходимость "выдернуть" разработчика от его текущей задачи в "in dev" - это полностью на его усмотрение, так?
источник

M

Marina in QA Сибирь
ну как сказать... если разработчик увидел не только то, что в его задаче заведены баги, но и обратил внимание на их приоритеты - это, бывает, уже успех...
источник

A

Aleksander in QA Сибирь
Плюс у нас для каждой фиче свой чат создается. Где PM, QA, Dev. И там принято говорить про проблемы и думать что с ними делать.
В общем не бывает у нас такого что dev не знает про баги на своих новых фичах
источник

‌‌‎Оо in QA Сибирь
Не сталкивался с проблемой. Думаю, такое можно решить на уровне обычных переговоров, выстраивая процесс
источник

M

Marina in QA Сибирь
Дело ж не в "не знает". А в том самом "несёт ответственность за непосредственное движение задачи дальше" :)
Но в целом - ответы ясны, спасибо большое)
источник