Заводим баг-репорты по мере выявления

смотря что за баги нашлись. если очевидно, что сборка не удалась , то зачем проверять дальше. возможно поможет пересборка. а если "поехал" функционал - то, конечно, стоит закончить

не обязательны. Опыт ценят и знания. По опыту могу сказать, что после курсов приходят валенки. Нужно искать хорошие курсы

нацеленные именно на твою работу. Веб, мобильные, декстоп. Обычно что-то общее, а по факту знаний мало

И это хорошо. Я больше клоню в ту сторону, что лучше выявить все возможные баги сейчас, чем ждать фиксов и пересборки.

Мало того, те оставшиеся 2/3 проблем, которые вы не озвучили, могут очень сильно влиять на то, как нужно править озвученные баги.

UPD: Зная, что в чате много людей, которые хотят "поспорить". Я озвучиваю лишь одну точку зрения и свой опыт. Конечно же ситуации могут быть совершенно разными и зависеть от продукта и условностей в команде.

Накатили ежегодное обновление системы от разработчика

Так же важно понимать, все последующие баги имеют одну причину или это совершенно разрозненные проблемы. Если причина одна, то можно дождаться её решения и потом перепрогнать смок заново.

Можно спросить у разработчиков или менеджером, как так получилось. Может они сильно накосячили в сборке или проводили какой то эксперимент и вся ваша работа по поиску багов бессмыслен

Вариантов много что делать, но надо понимать всю ситуацию целиком. Само по себе 20 багов это просто число вырванное из контекста

Пересборки не будет, ежегодное обновление от "производителя"

+
обсудить надо обязательно

Ааа, т.е. мы говорим о тестировании продукта, который вы хотите накатить себе для использования в компании?

Мы уже его используем) дорабатывает подрядчик, а есть версия системы "из коробки" от разработчика системы

Ну то есть крупная известная десктоп-система

Есть согласованный тестовый набор

А что у вас так обновилось, что уже в смоуке столько багов? Возможно, стоит ещё и процессы сразу пересмотреть, чтоб в следующий раз такого не было? Представь, сколько багов тогда на регрессе выплыть может)

Было много доработок "под себя", а есть "стандарт", и вот обновление этого "стандарта" мы и накатили поверх наших доработок

Тут тогда очень много вопросов появляется. Вы тестируете обновление поверх основного продукта или поверх того, что сделали подрядчики? Что, если в основном продукте изменились интерфейсы, а подрядчики просто не поддержали эти изменения. Делает ли разработчик продукта приватные фиксы именно под конкретных кастомеров с их проблемами? Нужно ли вам это обновление настолько, что работать остановится?

Тут очень много неизвестного, к сожалению.

Это уже вопрос ваших взаимоотношений с подрядчиком. Лучше с ваши менеджментом решить, как они смотрят на то что вам дают сырой продукт

Как я и написал чуть позже, "стандарт" мог измениться. Баги случайно не связаны с этими изменениями? Может подрядчикам нужна новая спецификация и фиксы на своей стороне.

Смысл смоука в нашем случае - определить стоит ли накатывать данное обновление в прод