Пока по 4 еще, там что то с хостами кубера, пока у девопсов нет времени глянуть. Обещали дать права чтобы я сам поковырялся

Спасибо 🙏

круто

минимально - это трекаем code coverage в динамике там где это делать легко (всюду кроме браузерных тестов) и репортим разницу между master и feature branch как коментарий к PR. Если же про браузерные тесты - то тут зависит от конкретной команды (в некоторых командах QA умеют сами тесты писать, в некоторых нет). Но от этого definition of done не меняется - тесты должны быть написаны и все. Как минимум надо покрыть happy path scenario (как раз тут часто QA следят за тем чтоб нужные сценарии были покрыты тестами). Тесты проходят тот же код ревью что и остальной код и если их нет или покрыто не то что нужно или еще какой косяк - то это обычно сплывает на этом этапе.
А фичи бывают разные - от пару часов до 1 месяца. Но мы стараемся не держать долгоживущих бранчей и если есть какая-то фича которая разрабатывается долго - то ее просто прячут под feature-toggle и мерджат в мастер код (правда тут браузерные тесты на новую фичу пишут позже, перед тем как ее выкатывать на всех пользователей).
Провести баг фикс через весь пайплайн до продакшена занимает меньше часа

просто у нас продуктовая компания (SAAS) и подход к разработке "you build it - you run it" (все девелоперы учавствуют в On-Call rotation, потому лучше сделать хорошо чтобы потом по ночам не будили через PagerDuty)

Cool

Большое спасибо за развернутый ответ!

У нас очень многие вещи реализованы тем же самым образом: отсутствие ручного тестирования, релиз по кнопке, фиче-флаги, кавередж, мониторинг и возможности быстрого баг-фикса в крайнем случае и так далее.

Но, в отличие от вас, камнем преткновения у нас служит точка перехода кода из ПР в мастер. Не хочется выступать батл-неком, чтобы куа мониторили "достаточность покрытия" той или иной фичи, но одновременно с этим сложно поднимать культуру разработки до уровня, где QA не были бы нужны в этом процессе совсем. Часто встречал на практике, что разработчику не всегда хочется/сложно автотестить дальше happy-path и поэтому то тут, то там проезжает что-то что можно было бы отсечь на этапе ПР. Зачастую не такое страшное, потому что все страшное закрыто достаточно хорошо, но все же неприятно.

ну у нас тоже все далеко не идеально и не всегда код/тесты ревьювит QA, и тоже пролазят мелкие регресионные баги (и в продадакшен тоже). Но с точки зрения бизнеса это ок, потому что откатиться на прошлую версию или задеплоить багфикс можно очень быстро. Плюс из каждого косяка мы стараемся делать урок и смотреть что нужно сделать чтобы избежать такой ситуации в будущем. В результате мы либо:
- вносим правки в тесты, чтобы они отлавливали такого рода баги
- либо смотрим что изменить в процессе
- либо смотрим что изменить в архитектуре системы чтобы избавиться от проблемы в корне.

Ну и да, QA в нас это необходимость, и мы не собираемся от них избавляться. Потому что все новые фичи которые под feature toggle тестируются вручную кое-какое время перед тем релизом на всех пользователей (и тут без QA знающего продукт достаточно хорошо и понимающего как текущая фича может повлиять на остальной продукт нам не обойтись)

У нас несколько разных проектов и где-то по 250-300 тестов на каждом написанных на wdio. Есть селениум ферма из трёх мак мини на Интел. Опытным путём выявил что держит 55 браузеров одновременно. Собственно нагрузку в 50 в параллель и даю на некоторых проектах. На других 20+, так как затыки начинаются на некоторых сервисах и пока ещё не затюнили.
Чтобы все это ранить не со своей машинки (иначе макбук прямо начинает выть и лагать из-за большой активности) есть ещё виртуальная машина, на которую баш скриптом копируется код проекта через rsync и запускается команда с этой машины. В webstorm добавлена конфигурация, которая по клику всю эту магию запускает и синкает логи.
Ну и собственно планы через пайплайн таким же путём запускать из гитлаба в будущем 😅

круто

да ещё не известно, к проекту новому готовлюсь

В плейврайт тест шардинг тестов прям встроен, очень удобно

Для небольших проектов - бесплатен. А остальное да, кушать хочется)

главное чтоб кодсепт платным не стал, а то вообще тяжело станет)

даже не знаю как будет работаться без этого

К счастью, пока кушать есть что 🤓
Тем более кодсепт сейчас донаты собирает и более менее их хватает. Но если есть возможность, можете убедить вашу компанию докинуть

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

В синхронном режиме wdio, если вызывать isDisplayed в асинхронной функции, он становится промисом?

не стоит мешать async\sync код в  wdio

но вообще да.