Комментарии 6
Спасибо за статью, но не мог не отметить пару моментов в ваших сценариях.
Ситуация 1 – Новые баги
Тут сразу во всей ситуации напрашивается первый и как мне кажется единственно правильный шаг. Написать разработчику. Например: "Привет, Максим, я тут проверял такую-то задачку и заметил, что твой фикс вызывает новые баги. Далее кинуть Максиму баги, их воспроизведение и стектрейс. Я уверяю, что в 90% случаев Максим просто и быстро починит эти проблемы. Скорее всего он просто допустил ошибку и не заметил. В остальных 10% мы действительно переходим уже к вашим возможным решениям.
Ситуация 5 – Завтра релиз, а ничего не готово
что сделать, чтобы запуск состоялся успешно?
Ответ тут по сути один (ваш третий пункт): Мы закладываем достаточно времени на тестирование нового функционала после того, как готов бэкэнд. К сожалению, остальные решения - не панацея, а могут привести к недостоверным результатам тестирования и упущению потенциальных проблем, которые могут возникнуть в реальной среде. Те же моки не тестируют реального клиент-серверного взаимодействия, интеграцию с внешними сервисами, платежи и т.д. Отключение фичи работает только при ее достаточной изолированности, что на практике происходит редко. А внеплановый релиз может нарушить планы и порядок развертывания.
Ищите компромисс между качеством продукта и задачами бизнеса, ваша задача найти и указать на проблемы, нельзя взять и сказать “я не буду тестировать без бэкенда и точка”.
Да, так говорить нельзя, вы правы. Но так же надо понимать, что без готового бэкэнда вы не сможете дать вашу полную оценку готовности продукта к релизу. И ответственный за релиз должен это понимать. Важно уметь идти на компромисс, но не менее важно и уметь отстаивать свою позицию в данной ситуации, ведь большая степень ответственности за качество лежит именно на вас.
Привет, спасибо за ответ, и что прочитали)
1
К сожалению, это самая большая ошибка - навалить все баги вместе разработчику в лс и нигде больше про них не писать.
Да, Максим может починить всё сразу, а может починить но не всё, а может он сейчас работает над другой задачей и обещает вернуться через пару дней.
А что если он заболеет, задачу надо передать кому-то, а ты даже статус не поменял, или поменял, но не понятно что не так, а потом и ты в отпуск уходишь и другой тестировщик после фиксов не знает что смотреть.
В целом это все те же проблемы, если писать баги в комментариях, только ещё хуже, я об этом писал тут https://t.me/LilBugHunters/39
Я не говорю, что в лс не надо писать, но всё что было в лс надо вынести как минимум в описание задачи, чтобы никто не потерял контекст. Завести баг это дело 5 минут.
5
Тут немного не понял, если не выполнить предыдущие пункты (проверить на моках, проверить обработку ошибок, и возможность закрытия фичи) то и до третьего пункта не добраться.
Фичу нужно сразу разрабатывать с изолированным подходом, если это будет на уровне процессов разработки подразумеваться, то случаи, когда невозможно сделать управление с бэка будут довольно редки.
Поэтому и пишу, что нужно предложить, а решение принимать уже совместно с командой на основании рисков и того насколько новая фича важна.
большая степень ответственности за качество лежит именно на вас.
да, поэтому мы и должны подсветить все возможные риски и попробовать найти лучшее решение.
Да что ж тут за любовь авторов к утрированию и усложнению.
Да, вместе с личным сообщением разработчику, мы естественно переоткрываем баг, чтобы он был в статусе Reopened, я думал, что это очевидно (ну или разработчик сам сделает, не суть). И нет, мы не пишем комментарий к задаче.
Теперь по вашим комментариям.
К сожалению, это самая большая ошибка - навалить все баги вместе разработчику в лс и нигде больше про них не писать.
Мы с вами обсуждали как один баг вызывает новые, теперь вы пишите про "навалить все баги", пожалуйста не выдумывайте, речь про конкретную проблему.
Да, Максим может починить всё сразу, а может починить но не всё, а может он сейчас работает над другой задачей и обещает вернуться через пару дней.
Ну так для этого мы ему и пишем! Что ж вы с разработчиками не хотите взаимодействовать. Напишем, уточним приоритеты.
А что если он заболеет, задачу надо передать кому-то, а ты даже статус не поменял, или поменял, но не понятно что не так, а потом и ты в отпуск уходишь и другой тестировщик после фиксов не знает что смотреть.
Я редко помню, чтобы реопены чинили другие разработчики. Опять же, я говорю про 90% случаев, в которых реопен починит этот же разработчик, который уже разобрался с функционалом и ему будет проще решить проблему. И чаще всего после болезни сам и сделает, никто не полезет в фичу разработчика, с которой он месяц разбирался.
Я не говорю, что в лс не надо писать, но всё что было в лс надо вынести как минимум в описание задачи, чтобы никто не потерял контекст. Завести баг это дело 5 минут.
Если вы оутсорсер и вам платят за каждый заведенный баг - welcome. Цель тестирования - не заводить баги. Наша цель улучшать качество продукта и внутренние процессы тестирования и разработки. Если вы хотите качественно решить задачу - решаем через взаимодействие с разработкой, находим лучшее решение (там могут быть и новые баги, и комментарии к старым, и т.д.). Если один фикс бага вызывает три, то самое последнее дело - завести три новых бага, не предупредить разработчика (вы тем самым и подставляете его, а еще это может обернуться ворохом проблем, которые вы с позиции тестирования даже себе не можете предположить).
Фичу нужно сразу разрабатывать с изолированным подходом, если это будет на уровне процессов разработки подразумеваться, то случаи, когда невозможно сделать управление с бэка будут довольно редки.
Редки ситуации, когда вы можете полностью изолировать фичу от остального функционала. Ну только если у вас очень хорошая и отлаженная система микросервисов. Тогда да, спорить не буду, так можно. При использовании монолита, можно выстрелить себе в ногу, там очень много технических и других зависимостей, которые надо учитывать.
Ну немного сутрировал про статус, всего остального это не меняет)
1 Ну да речь шла как раз, если фикс бага вызывает несколько новых, но кстати вы верно подметили, (хотя наверно не хотели) разработчик может одновременно общаться с вами по поводу нескольких разных задач и если всё оставлять в лс контекст быстро теряется
2 Я не знаю почему вы решили, что я говорю, что разработчику ничего не надо писать, как раз таки написать надо, речь про визуальное представление, если багов несколько, то очень легко разработчику не обратить внимание на один из пунктов, что ты написал, а тебе потом забыть его чекнуть, особенно если между сообщениями о багах было несколько других
4 Если заведение багов как-то подставляет разработчика и приводит к проблемам, то что-то не так с процессами, количество багов не может являться критерием оценки качества, с таким подходом вы будете в один баг сразу несколько засовывать, теряя атомарность.
Цель не в заведении багов, вы чтот не так поняли, цель представить ясную четкую атомарную картину по проблемам, которые нашлись, чтобы просто взглянув на тикет было понятно статус, чтобы ни вы потом после фикса, ни разработчик во время фикса не рылся в чате, в котором вы позавчера обсудили баги и никуда не записали. Плюс все эти связи могут быть полезны в будущем после закрытия задачи, если например возникнет аналогичный баг - сразу видны идеи для регресса.
Ещё раз отмечу что основная мыль была не в заведении багов, а в том чтобы отметить в тикете, что эти баги есть.
Это всего лишь удобный инструмент для организации задач для всех участников, он не отменяет ваши процессы, а наоборот улучшает их, общение с разработчиком никто не отнимает и не отменяет.
Я не знаю почему вы решили, что я говорю, что разработчику ничего не надо писать
Это отсутствует в вашей статье изначально в принципе в этом сценарии. А я как раз указал, что по мне это важный пункт, ведь он решает большинство проблем. Напиши вы про это, и не было б моих комментариев) Если он подразумевается, то мои извинения, я лишь сделал акцент на этом. Другой пытливый ум может это не понять, посмотреть вашу статью и начать сразу же заводить три новых бага, не пытаясь разобраться.
Если заведение багов как-то подставляет разработчика и приводит к проблемам, то что-то не так с процессами, количество багов не может являться критерием оценки качества, с таким подходом вы будете в один баг сразу несколько засовывать, теряя атомарность.
Ну вы читайте внимательно: "не предупредить разработчика (вы тем самым и подставляете его...". Речь опять же про взаимодействие и коммуникацию с разработчиком. Стоит хотя бы предупредить о проблеме и какие новые баги она вызывает.
Опять же, я не против пунктов про заведение новых багов. Я просто повторюсь, что все это не обязательно и не первостепенно, и скорее всего вся проблема решится простым взаимодействием QA - Разработчик. Вы просто переоткрываете баг, пишите девелоперу, в чем новые проблемы, по моему опыту он в 90% просто решает эти проблемы. Итог: баг починен, не заведено три новых ненужных бага, разработчик в курсе, так же не возникли потенциально те проблемы, которые QA не увидел со своей колокольни. В остальных 10% мы действительно смотрим по описанному вами флоу.
Путь к надёжности: как QA инженеру действовать в нестандартных ситуациях