нашли 20+ дефектов в трети тестового набора из прогона?
Не лишено смысла его закончить. Возможно там есть более 20 багов. Если вы не заведёте их сейчас, то в следующем билде у вас будет исправлена лишь часть ошибок и смок снова не пройдёт, но уже по оставшимся 2/3 багов (а вы могли сообщить о них ранее). Если билд продукта собирается долго, то вы впустую потратите это время.
Заводим баг-репорты по мере выявления
смотря что за баги нашлись. если очевидно, что сборка не удалась , то зачем проверять дальше. возможно поможет пересборка. а если "поехал" функционал - то, конечно, стоит закончить
И это хорошо. Я больше клоню в ту сторону, что лучше выявить все возможные баги сейчас, чем ждать фиксов и пересборки. Мало того, те оставшиеся 2/3 проблем, которые вы не озвучили, могут очень сильно влиять на то, как нужно править озвученные баги. UPD: Зная, что в чате много людей, которые хотят "поспорить". Я озвучиваю лишь одну точку зрения и свой опыт. Конечно же ситуации могут быть совершенно разными и зависеть от продукта и условностей в команде.
Накатили ежегодное обновление системы от разработчика
Так же важно понимать, все последующие баги имеют одну причину или это совершенно разрозненные проблемы. Если причина одна, то можно дождаться её решения и потом перепрогнать смок заново.
Пересборки не будет, ежегодное обновление от "производителя"
Ааа, т.е. мы говорим о тестировании продукта, который вы хотите накатить себе для использования в компании?
Мы уже его используем) дорабатывает подрядчик, а есть версия системы "из коробки" от разработчика системы
Ну то есть крупная известная десктоп-система
А что у вас так обновилось, что уже в смоуке столько багов? Возможно, стоит ещё и процессы сразу пересмотреть, чтоб в следующий раз такого не было? Представь, сколько багов тогда на регрессе выплыть может)
Было много доработок "под себя", а есть "стандарт", и вот обновление этого "стандарта" мы и накатили поверх наших доработок
Тут тогда очень много вопросов появляется. Вы тестируете обновление поверх основного продукта или поверх того, что сделали подрядчики? Что, если в основном продукте изменились интерфейсы, а подрядчики просто не поддержали эти изменения. Делает ли разработчик продукта приватные фиксы именно под конкретных кастомеров с их проблемами? Нужно ли вам это обновление настолько, что работать остановится? Тут очень много неизвестного, к сожалению.
Как я и написал чуть позже, "стандарт" мог измениться. Баги случайно не связаны с этими изменениями? Может подрядчикам нужна новая спецификация и фиксы на своей стороне.
Смысл смоука в нашем случае - определить стоит ли накатывать данное обновление в прод
Сейчас обновление крутится на промежуточной тестовой среде
С чем связаны баги предстоит разобраться разработчикам
Это же не смок)))
А можно вопрос а чем у вас Куа во ыремя регресии занималмя если вы столько багов ыо время смока нашли?
Регресс и смоук могут не пересекаться. Ваш кэп.
Я говорю о фул регресии
А не выбранных частей что в последнее время стало актуальным но приэтом и качество гарантировать вы не можете
Не хочу докапываться до слов, но ни смоук ни регрессия не могу "гарантировать качество"
Почитайте ниже. Там не совсем стандартная ситуация тестирования.
Накатили ежегодное обновление от разработчика поверх своих доработок, цель - определить можно ли в проде обновлять
Обсуждают сегодня