Комментарии 8
Разделим регресс на две большие части:
ядро регресса;
тесты, проверяющие новый функционал.
Как по мне - тут вводит в заблуждение всё. И нумерация частей (которая может подразумевать порядок выполнения). И то, что вы "тестирование НФ" считаете подмножеством тестов регресса.
С моей точки зрения тестирование НФ можно считать частью предрелизного тестирования. И если говорить про предрелизное тестирование, то тогда можно будет формулировать так:
Тестирование релиза перед выпуском можно делить на две части
Тестирование НФ
Регресс
И выполнять последовательно именно в перечисленном порядке. Потому что как только вы при тестировании НФ нашли ошибку, требующую исправления, так сразу после исправления ошибки у вас новая версия продукта. И для новой версии продукта тоже надо будет выполнить регресс. Поэтому тестирование НФ (вместе с починкой найденных багов и верификацией) выполняют до регресса.
Кроме того, сам регресс может найти блокирующие выпуск релиза ошибки. И тогда придется повторять цикл регресса. По опыту редко удается обойтись одним циклом.
Про количество тестов в ядре регресса можно говорить долго. Обычно это считается по другим метрикам (где-то тут для сокращения количества тестов на регресс надо будет применять техники тест-дизайна). Хотя при расчете учитывается в том числе и доступные ресурсы.
Замечание справедливо, если не успевать тестировать НФ до регресса. Обычно оно у нас все-таки протестировано и описано в новых тестах до начала выпуска нового регресса. Поэтому и используем такое деление. Часть новых тестов потом войдет в ядро регресса, а остальные отправятся в архив до момента, когда в работе будет задета данная функциональность. В каком порядке проводить — это уже дело вкуса. Главное, чтобы все выбранные тесты были пройдены.
Редко дадут время на повторное прохождение всего цикла регресса, особенно если в проекте нет автоматизации. Поэтому максимум — проверка бага, перепрохождение теста, давшего ошибку, и то, редко дадут время на повторное прохождение всего цикла регресса, особенно если в проекте нет автоматизации. Поэтому максимум — проверка бага, перепрохождение теста, давшего ошибку, и то, что тестировщик успевает проверить. Это ближе к реальности.
Замечание справедливо, если не успевать тестировать НФ до регресса.
Обычно оно у нас все-таки протестировано и описано в новых тестах до
начала выпуска нового регресса.
Я не совсем понимаю. Вам нравится дублировать работу?
Если вы уже протестировали НФ до начала регресса, то зачем вам повторно заниматься тестированием НФ во время регресса?
Для того, чтобы часть тестов НФ стала регрессом, вы сначала должны выпустить текущий релиз и перейти к следующему циклу разработки НФ. Пока вы текущий релиз не выпустили, НФ текущего релиза отдельно, регресс отдельно. НФ тестируется в первую очередь, и лишь потом приступают к регрессу.
пока у вас нет этой четкой картинки предрелизного тестирования, есть вероятность того, что вы блокирующий баг в НФ найдете после регресса. Т.е. весь регресс проделаете зря.
Конечно, есть лайфхаки типа "баг затрагивает только вот этот кусочек функционала, поэтому переделывать регресс будем только для этого маленького кусочка продукта". Но даже с этим лайфхаком вы все равно будете переделывать то, что можно было не переделывать.
То, что вам редко дают время на второй цикл регресса - не означает, что нет смысла во втором цикле. И может быть имеет смысл выпускать релиз со списком известных багов вместо того, чтобы исправлять баги без надлежащей проверки продукта после исправлений.
Двойную работу не нравится делать никому. Это факт. Но тесты по НФ лучше включить в регресс, т.к. коммит с исправлением по нему или вообще часть НФ могут забыть добавить в релиз. Можно проверять НФ и в середине спринта, а потом его сломают при починке бага где-то еще.
С последним абзацем согласны. Но опять же, если баг не выше третьего и до выпуска продукта осталось меньше дня ?
Но тесты по НФ лучше включить в регресс, т.к. коммит с исправлением по
нему или вообще часть НФ могут забыть добавить в релиз. Можно проверять
НФ и в середине спринта, а потом его сломают при починке бага где-то
еще.
Проверку НФ лучше включить не в регресс, а в предрелизное тестирование. А перед этим не забыть выполнить цикл проверки сразу после разработки.
Регресс - это проверка состояния старого функционала, который уже был в предыдущем релизе.
А чтобы коммит с исправлением НФ не забыли добавить в релиз, нужно не забыть, что жизненный цикл бага завершается не тогда, когда на рабочей станции у разработчика всё работает, а когда баг верифицировали на выпущенной версии продукта.
И что предрелизная стадия тестирования НФ включает в себя верификацию найденных багов.
Все подводные камни, описанные вами, легко обойти зная жизенный цикл разработки продукта. Ощущение, что вы сами старательно раскладываете грабли из-за плохого знания жизненного цикла, а потом героически терпите боль от собранных граблей.
Пример с забытым коммитом как бы намекает на бардак в тестировании и разработке.
От себя добавлю, что главное — с чего-то начать, например, выбрать хотя бы первые 10 тестов.
Это неправильный подход к автоматизации регресса. Тут два основных подхода. Или же мы выбираем самые затратные по времени ручные тесты или же мы выбираем самые сложные сценарии для подготовки среды, пользователей и т.д.
И вот уже в зависимости от этого мы составляем приоритет для покрытия автотестами нашего регресса. И делаем задачи согласно приоритету.
Тут два основных подхода: мы выбираем или самые затратные по времени ручные тесты, или самые сложные сценарии для подготовки среды, пользователей и т. д.
Выбрав самые сложные, можно потратить много времени и ничего хорошего не получить. Например, автоматизация отчетов: много допбиблиотек, неустойчивы из-за зависимости от данных, да и нужно придумывать, как парсить пдф или перелавливать результат до формирования файла. А функционал не основной. Любой ручник потратит не более получаса. Невыгодно.
Поэтому я и сказал, что речь про подготовку среды, пользователей и прочие пререквизиты, когда настройка окружения занимает существенное время и вызывает дополнительные сложности. Как вариант - настройка кастомного образа для виртуальной машинки для анализа файлов на киберуязвимости. Когда каждый регресс приходилось делать много сложной работы по настройке нужного образа и его нельзя было подготовить заранее, потому что надо было проверять полноценную установку и работу с определенным набором программ. Вот тогда автотесты экономят много времени и мы избегаем дополнительных сложностей с настройкой.
А так да, если функционал не основной и сами автотесты сложнее, ненадежнее и нестабильнее ручных проверок, то понятное дело эти факторы учитываем для приоритета автоматизации.
Еще раз о регрессе: почему тестирование до сих пор вызывает вопросы?