Комментарии 10
Я не имею отношения к коммерческому программированию, и наверняка просто чего-то не догоняю. Но просветите меня, зачем бизнесу надо 30 релизов в день? Какой в этом смысл, и почему их недостаточно, как вы писали, двух в неделю (что по мне тоже довольно часто)? Со стороны выглядит, что в погоне за скоростью, вы потеряли здравый смысл, что это технологии ради технологий. Не лучше ли подкрутить что-то в "бизнесе", чтобы ему не нужно было получение обновлений, как из пулемёта? Выглядит, как погоня менеджеров за каким-то люто-бешенным KPI, оторванным от реальности, вопреки реальной пользе. Почему это пользователи не могут подождать новой фичи со вторника до пятницы, а могут только с 13:30 до 14:00?
Речь же про web, а не standalone приложение. Веб-сервисы можно релизить в любой момент по требованию, главное чтобы поставка умела сине-зеленые релизы под нагрузкой.
Поверьте, бизнесу куда выгоднее иметь непрерывный цикл поставки, чем кумулятивные релизы по расписанию. Что легче тестировать, релиз с одной фичей, или десяток фич в релизе? А откат или фикс бага? Как говорится "удачной отладки", чтобы найти причину в релизи с десятком фич
Как часто бывает, любой объективный абсурд проистекаеи из чьего-то субъективного заблуждения. Еще мне это напоминает рекорды гиннеса, например какой-нибудь самый дальний выстрел зефиркой из ноздри в мире. Или зачем хорошо-идеально делать то чего делать совсем не нужно!
а вообще вот такая JS автоматизация тестирования на Cucumber или Puppeteer сильно распространена? Или не стоит в это лезть и сразу двигаться в сторону Java и Python + Selenium?
Думается мне, это пространство субъективного. Например желание скрыть фигню за фантиком. Или же, желание сделать что-то красиво чтобы показать другим. Вобщем, не объективная потребность, скажем так. Мыльный пузырек + вагон рационалзаций!
Пользуюсь СберЗдоровьем и как пользователь чето в упор не понимаю где там "30 релизов в день"? Сори, приложенька вообще половины функционала не содержит, да и решения на сайте - не прорыв в технологиях и юзер-фредли.
Здравствуйте! А где можно узнать вакансии в Сбере? ? интересуют тестировщики)
Как обычно - юзаем webdriver потому что не потрудились сделать приложение тестируемым
Несколько мыслей вслух:
Первое правило оптимизации авто-тестов - выкинуть как можно больше бесполезных UI тестов, особенно таких как на 1-ом скриншоте
Gherkin + json - очень скоро вы будете себя ругать на чем свет стоит
as a side note: зачем вообще тогда нужен геркин? Это все еще человеко-понятный формат у вас там? :)
selenoid в помощь вместо грида, если некритично, что браузеры будут запускаться в докере. Он умеет и в k8s
вместо webdriver при старте чего-то нового рекомендую попробовать playwright - во многих случаях избавляет от головной боли и необходимости писать свою очередную супер-крутую обертку над WD (любители писать слипы точно должны оценить). Ну и море удобных плюшек в комплекте
вообще если хочется много ui-тестов, то можно мокать бэкенд для ускорения / стабилизации
а еще лучше - большую часть тестов сгрузить на нижние уровни. Для тестирования отдельных ui-компонентов и их интеграции (даже в целые страницы) хватает инструментов (например react testing library, под капотом jsdom)
> на тяжёлых страницах (например, список врачей)
звучит так, как лечите симптом. Уменьшить кол-во тестовых данных, оптимизировать перфоманс - не?
> В итоге мы сформировали светофорную систему: от одного до трёх перезапусков для разных типов тестов
аналогично - звучит, как будто лечите симптом. Вообще, можно делать retry как для экшнов так и для проверок прямо в самих тестах (без перезапуска теста целиком)
Как мы научились запускать 10-часовые UI-тесты за 5 минут в условиях 30 релизов в день