👉 Если хотите участвовать в разборах, присоединяйтесь в NoBugs телеграмм: t.me/nobugs_me ✍ ДОЛГОЖДАННАЯ Анкета предзаписи на след поток QA Auto с нуля [PRO уровень]: nobugs.me/wtf/preregistration
супер живой, интересный кейс, затрагивает все аспекты хотеть ещё) я как раз нынче учусь собеседовать кстати отличная идея рассказать как собеседовать автоматизаторов какие вопросы, кейсы какого рода лайвкодинг применить на что обращать внимание
Если честно, ничего не понял: даже если разработчик запушил изменение напрямую в ветку, то API автотест, относящийся к этой ветке должен был по-любому проверять измененный код в целом, независимо от того как изменение попало в ветку и по-любому упасть на этом изменении, даже если оно смерджено напрямую без ревьювера. Или автотест тупо не запустился, потому что он следит и запускается только от тех изменений, что были смерджены через ревью? Если так, то почему дополнительно не поставить автотесты на шедулер, чтобы они запустились ночью, когда код никто не трогает и утром проверить статус автотестов?
Нормальный пайплайн такой: 1. Создается feature-ветка и PR с запросом на мердж в релиз ветку 2. На каждый коммит запускается пайплайн, частью которого являются автотесты с Quality Gates. Нельзя залить PR с упавшими Quality Gates 3. Когда ревью закончено, PR мерджится. Шаг 2. не был пройден, поэтому разработчик перенес изменения в релиз ветку и напрямую закоммитил и запушил.
@@alexpshe понятно, вы предполагали что иного пути, как зачекинить через review нет, а оно оказалось не так. Ну я бы все-таки подумал в качестве дополнительной меры безопасности запускать тесты в ночное время с разбором статусов на следующий день. Да дефект обнаружится на следующий день, но главное что он не попадет в Продакш, потому что принудительный запуск всех API тестов в ночное время возможно выявил бы не только эту, а ещё одну-две подобных проблем, ведь не исключено, что кто-то ещё из программистов заметил "уязвимость" и пользовался ей. :)
@alexpshe Да все что вы сказали оно, конечно, правильно, но что мешает запускать регрессию перед мержом релизной ветки в прод? Когда уже ну все все коммиты в релизной ветке и больше ничего меняться не будет. А на каждый коммит запускать тесты - ну разве что смоук небольшой. Потому что девелоперы бывает коммитят как не в себя в рабочую фича ветку. И если у вас например за время прогона нужно платить, как в том же github actions, то накладненько может выйти... мы пришли к тому, что автотесты запускаются в фиче ветке руками перед мержом в релизную, а если кто-то это забыл сделать, то есть правило, что автоматом тесты запускаются после мержа на релизной уже ветке... и если тут что-то упало, то всегда можно реверт мержа сделать, чтоб девелопер фиксил и не забывал в будущем запускать тесты до мержа)))
![QA КЕЙСЫ С СОБЕСОВ [PRO]: флаки UI регрессия](http://i.ytimg.com/vi/6Soxe_dkMp8/mqdefault.jpg)
![QA КЕЙСЫ С СОБЕСОВ [PRO]: флаки UI регрессия](/img/tr.png)
👉 Если хотите участвовать в разборах, присоединяйтесь в NoBugs телеграмм: t.me/nobugs_me
✍ ДОЛГОЖДАННАЯ Анкета предзаписи на след поток QA Auto с нуля [PRO уровень]: nobugs.me/wtf/preregistration
Предыдущее видео пересмотрел только 2 раза и уже новый ролик😊
Саша, спасибо тебе за интересный, понятный разбор! Коммент в поддержку канала.
супер
живой, интересный кейс, затрагивает все аспекты
хотеть ещё)
я как раз нынче учусь собеседовать
кстати отличная идея рассказать как собеседовать автоматизаторов
какие вопросы, кейсы
какого рода лайвкодинг применить
на что обращать внимание
Наберите слово ПШЕ при включённой английской раскладке.
А, впрочем, работающие с кодом люди и без меня заметили.
Спасибо. Интересный кейс и разбор
Красотка🧡
Если честно, ничего не понял: даже если разработчик запушил изменение напрямую в ветку, то API автотест, относящийся к этой ветке должен был по-любому проверять измененный код в целом, независимо от того как изменение попало в ветку и по-любому упасть на этом изменении, даже если оно смерджено напрямую без ревьювера. Или автотест тупо не запустился, потому что он следит и запускается только от тех изменений, что были смерджены через ревью?
Если так, то почему дополнительно не поставить автотесты на шедулер, чтобы они запустились ночью, когда код никто не трогает и утром проверить статус автотестов?
Нормальный пайплайн такой:
1. Создается feature-ветка и PR с запросом на мердж в релиз ветку
2. На каждый коммит запускается пайплайн, частью которого являются автотесты с Quality Gates. Нельзя залить PR с упавшими Quality Gates
3. Когда ревью закончено, PR мерджится.
Шаг 2. не был пройден, поэтому разработчик перенес изменения в релиз ветку и напрямую закоммитил и запушил.
@@alexpshe понятно, вы предполагали что иного пути, как зачекинить через review нет, а оно оказалось не так.
Ну я бы все-таки подумал в качестве дополнительной меры безопасности запускать тесты в ночное время с разбором статусов на следующий день. Да дефект обнаружится на следующий день, но главное что он не попадет в Продакш, потому что принудительный запуск всех API тестов в ночное время возможно выявил бы не только эту, а ещё одну-две подобных проблем, ведь не исключено, что кто-то ещё из программистов заметил "уязвимость" и пользовался ей. :)
@alexpshe Да все что вы сказали оно, конечно, правильно, но что мешает запускать регрессию перед мержом релизной ветки в прод? Когда уже ну все все коммиты в релизной ветке и больше ничего меняться не будет.
А на каждый коммит запускать тесты - ну разве что смоук небольшой. Потому что девелоперы бывает коммитят как не в себя в рабочую фича ветку. И если у вас например за время прогона нужно платить, как в том же github actions, то накладненько может выйти... мы пришли к тому, что автотесты запускаются в фиче ветке руками перед мержом в релизную, а если кто-то это забыл сделать, то есть правило, что автоматом тесты запускаются после мержа на релизной уже ветке... и если тут что-то упало, то всегда можно реверт мержа сделать, чтоб девелопер фиксил и не забывал в будущем запускать тесты до мержа)))