Size: a a a

2021 April 16

M

Marina in QA Сибирь
Мне всё-таки больше импонирует задачку по доске двигать, если честно)
источник

‌‌‎Оо in QA Сибирь
По-моему, в этом случае плясать надо от критичности найденных багов и времени на итерацию. Даже, скорее, есть ещё ряд факторов, которые надо учитывать, но они будут индивидуальны для команды/проекта. Т.е. вам должно быть виднее как лучше поступить
источник

OS

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

M

Marina in QA Сибирь
Да, конечно. Но я спрашиваю не для того, чтобы "сделать у нас так, как расскажут", а просто чтобы понять, какая ситуация у других людей)
Хотя местами перегибаю с вопросами, кажется :)
источник

M

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

ID

Ilya Doronin in QA Сибирь
Как по мне, то подход  "увидел и завел" может быть довольно опасным, но, как обычно, это зависит от многих факторов.
Опасность 1: много времени займет процесс заведения из-за чего тестирование и принятие решение о качестве затягивается. Иногда если понимаешь, что тестирование хотя бы по верхам займёт разумное количество времени и ничего не горит, то лучше протестить все и принять решение - релизим как есть и доделываем потом или возвращаем на доработку и ждем исправления. Иногда в процессе приходит понимание, что багов слишком много и проще всю фичу развернуть разработчику с просьбой протестить базовые кейсы самому (если их нет, то написать их в задачу) и не заканчивать тестирования.
Опасность 2: если задач с багами будет слишком много, то можно утонуть в тасках и МР-ах. К тому же ни кто не гарантирует, что исправление №1 после, допустим, исправления №5 будет работать корректно и не поломается из-за связанности багов - кажется разработчику проще видеть все баги сразу, возможно многие исправляются в одном месте.
источник

M

Marina in QA Сибирь
Всё по делу)
Правда, не очень ясно, как время на заведение багов зависит от времени их заведения.
И почему если возвращаешь разработчику - необходимо и самому продолжать тестировать Оо
источник

M

Marina in QA Сибирь
Ещё удивляет, что никто не упомянул смок-наборы, если честно...
источник

T

Timofey in QA Сибирь
В ответы, тоже сложно. Зависит от команды. По мне так зависит от критичности. Если совсем алярма, то правят сразу просто по переписке с фиксацией в jira. Если время и процессы позволяют, то через таски по каждому найденному багу, а дальше приоритеты от продуктовнера и лидов
источник

ID

Ilya Doronin in QA Сибирь
Тратя время на заведение не критичных багов (если по условию мы заводим все баги сразу, как находим), то постепенно откладывается время нахождения критичного бага, если он есть. А так можно отправить задачу на доработку и, например, в нее дописывать найденные баги. Я обычно делаю так - на критичные завожу таски или сразу или как прохожу основные кейсы, а миноры оставляют на потом, когда будет время - главное успеть их перед планированием завести, чтобы можно было в следующий спринт взять.
источник

ID

Ilya Doronin in QA Сибирь
Если речь про новую функциональность, где обычно багов больше всего, то смоук тесты тут вообще не применимы, так как на эту функциональность их нет.
источник

KK

Ksenia Krasotina in QA Сибирь
У вас как с коммуникациями в команде?
источник

M

Marina in QA Сибирь
мне так птичья память не позволяет - если не завести сразу, или хотя бы не записать в черновом варианте, забуду :)
источник

M

Marina in QA Сибирь
всё хорошо с коммуникациями)
эт просто я капризничаю и думаю итеративно тестировать. и стало интересно узнать мнения
источник

ID

Ilya Doronin in QA Сибирь
Я всегда все записываю в текстовый документ, потом сижу разбираю :) иногда пока руки дойдут завести, то уже баг и не воспроизводится 😂
источник

KK

Ksenia Krasotina in QA Сибирь
🍦
источник

KK

Ksenia Krasotina in QA Сибирь
Тоже так делаю, и бывает что баг не баг а сама накосячила, лишний перенос строки сделала или ещё чё..:)
источник
2021 April 17

СМ

Све Михайлова... in QA Сибирь
Не пройден acceptance-возвращай в разработку. Сами acceptance criteria пишутся до девелопмента в задаче и согласовываются заранее До начала имплементации с ответственным разработчиком. JFI acceptance criteria - это critical path сценарии с точки зрения бизнеса и технических рисков ( смотришь сам код в репке). Всё, что не прописано в acceptance criteria - пространство для маневра "стоит - не стоит"
источник

AR

Arseniy Rozov in QA Сибирь
а можн мне тож запись? 😌
источник

ОН

Олег Неумывакин... in QA Сибирь
источник