Пока планируем оффлайн-конфу, с онлайн-включением тех докладчиков, которые не смогут приехать.
Также прорабатываем план Б, который включает в себя как перенос конференции, так и полный переход в онлайн. Будем смотреть по ситуации, какой вариант для наших участников будет лучше.
Не, на codeFest не получается попасть. А можно ссылку на ваш доклад?
По поводу того, что тесты пишут все: тут как команда договорится. Как правило во всех командах аналитики как минимум могут собрать тест-кейсы из готовых шагов, но при этом новые шаги разрабатывать вообще не умеют. Чаще всего, чтоб требования не писать в отдельной доке — описывают уже тестами.
Java-разработчики не любят "программировать на русском языке". Просто это и программированием сложно назвать =).
Но когда команда нуждается в помощи из-за загруженности тестировщика, то проблем не возникало и писали тесты на ура.
Пару раз даже запускали команды без обучения тестировщика и вообще без тестировщика, так как того еще не смогли найти. И в команде автотесты писали сами разработчики. Реже всего привлекаются для этой задачи front-разработчики. Ибо js. И больше времени коммьюнити потом тратит, чтоб им объяснить и научить.
А как вы решаете проблему с тем, что к автоматизатору может случиться большой поток запросов от тестировщиков?
Приоритеты, очередь? Как это может повлиять на регрессию? Что случается в ситуации, когда автотесты сломались и регрессия из-за этого застопорилась?
Один из примеров — старт нового продукта. Как правило, это SPA-приложение, который практически не зависим от других подобных продуктов. Пересекаться они могут только, когда происходит изменение общебанковских сервисов, которые могут затронуть много систем, но это прям исключение из правил. И такие сервисы как правило покрывают тестами, чтоб сберечь обратную совместимость.
Поэтому, первые user story могут выглядеть вообще в стиле "Отобразить кнопку для такой-то категории клиентов". При условии, что все тесты на api пишутся на уровне unit — и e2e-тестов самими разработчиками, со стороны UI нужно выполнить тесты на поведение и интеграцию UI с API. И их опять же оказывается не так много, потому что все возможные логические и алгоритмические проверки для UI-компонент тоже зашиты в модульные тесты на UI, и пишутся фронт-разработчиком.
Багрепорты у нас заводятся тестировщиком, как тикеты в jira. А чаще всего не заводятся — а сразу же правятся разработчиком после приемочного тестирования. Только если баг не критичный, то заводится. Но вопрос приоритетности/критичности принимается совместно командой.
Я постаралась акцентировать внимание в конце статьи как раз на том, что заниматься разработкой тестового фреймворка тоже должна команда. А не выделенные люди.
И у нас, если тестировщик сталкивается со сложной задачей, где его навыков не хватает — реализацией занимается бекенд-разработчик из команды. Чаще всего они работают с тестировщиком в паре, за счет чего также происходит и передача навыков и та самая "прокачка" тестировщика. По поводу обучения:
Когда мы только пилотировали этот процесс — разработчики автотестов как раз и занимались обучением тестировщиков. Затем мы провели эксперимент и обучение провел java-разработчик, и оно никоим образом в своем качестве не пострадало.
Сейчас у нас обучение проводят уже сами "прокачавшиеся" тестировщики.
А зачем вы сделали фреймворк с технологиями, которые сильно отличались от того, с чем работали ваши разработчики? Наверное, потому что эти разработчики не участвовали в разработке этого фреймворка? Я понимаю, что на SAS, наверное автотесты писать бы не стали, но наверняка у ваших коллег опыт был/есть не только с этой платформой?
Для нас это было проблемой, потому что стоимость разработчика автотестов не маленькая. И естественно PO заинтересован по-максимуму использовать потраченные средства.
Если бы разработчик автотестов начал бы это свободное время тратить каким-либо другим образом на пользу команде/продукту, то наверное, его незанятость не так сильно бы бросалась в глаза.
И если недозагруженность сильная и регулярная — это повод задуматься.
А еще у нас была пара автотестеров, которые оказались недовольны своей незагруженностью и просили у меня дополнительные задачи.
Для нас это было проблемой, потому что стоимость разработчика автотестов не маленькая. И естественно PO заинтересован по-максимуму использовать потраченные средства.
Если бы разработчик автотестов начал бы это свободное время тратить каким-либо другим образом на пользу команде/продукту, то наверное, его незанятость не так сильно бы бросалась в глаза.
И если недозагруженность сильная и регулярная — это повод задуматься.
А еще у нас была пара автотестеров, которые оказались недовольны своей незагруженностью и просили у меня дополнительные задачи.
Рейты писателя скриптов пользовательских сценариев ниже рейта разработчика. Давая эту работу более дорогому специалисту вы только увеличите бюджет.
Для тестировщика нет разницы писать тесты в системе тест-менеджмента, типа HP ALM, куда они раньше тест-кейсы заводили; либо же эти тест-кейсы сразу как автотесты записывать. Библиотека реализована таким образом, что при ее регулярном использовании ты запоминаешь все ее шаги на память (их чуть больше 60), и собираешь тест-кейсы как в конструкторе. Как показал опыт, разработчик внутри команды привлекается редко, лишь тогда, когда тестировщик сталкивается с чем-то непонятным/незнакомым. Типа: реализовать шаги для тестирования интеграции с thrift-сервисом. Как правило, таких временных затрат за месяц набегает не больше 8 часов. Если сравнивать стоимость разработчика автотестов — и стоимость тестировщика, то в этом случае продукт получает экономию размером в еще один оклад тестировщика.
А когда менеджмент слаб — никакой божественный agile, к сожалению, проблем не решит.
Согласно скрам-гайду — команда, которая делает продукт, должна работать вместе. А не отдельными функциональными группами. Потому что, когда человек не является частью команды ответственной за продукт — качество его работы для этого продукта и эффективность будет сильно страдать.
Как только эффект новизны пройдет нерешённые проблемы в коммуникации и доверии сделают своё дело.
Эффекта новизны давно уже нет, так как пилотировали подход мы в 2016 году. А в 2017 процесс приобрел массовый характер. Из того, что я наблюдаю — у тестировщиков сформировалось свое коммьюнити, где они друг другу помогают в решении нестандартных проблем. К примеру, если кому-то нужен какой-то определенный шаг для автотеста, закидывается просьба в чат в slack, где либо находится владелец такого шага, либо коллега, готовый поделиться своим опытом.
Минусы статического грида я уже описала в статье. Получается, как минимум в статике мы не сможем поднять все нужные нам конфигурации нод. А если вспомнить о том, как много мы ловили проблем именно из-за нестабильности хаба и нод в статическом состоянии, то текущая концепция on-demand полечила все наши боли по этому поводу.
По поводу проблемы нехватки ресурсов. У Marathon есть одна особенность, когда он не может задеплоить контейнер из-за нехватки места, то задача висит в статусе ожидания, пока не появится место. А нам же ничего не мешает запустить тесты на том количестве нод, места для поднятия которых хватило.
То есть, отправили запрос в marathon на поднятие грида в 20 нод, а место у нас есть только для 5ти. Грид соберется и тесты запустятся на этих 5ти нодах в в параллельном режиме, все остальные тесты будут висеть в очереди на хабе. Как только у нас будет освободождаться место в кластере, то остальные ноды начинаются доподниматься и количество параллельных потоков увеличивается.
Также есть защита от "дурака", встроенная в сам фреймворк с тестами. Так как все наши приложения — это single page приложения, то нам сложно представить для такого приложения тестов в количестве больше 100. Поэтому устанавливаем ограничение сверху по количеству потоков, который проект может сгенерировать.
Ну а так как у нас еще не было проектов с 400+ тестов, то и конкретной проблемы еще не возникало. Как мне видится, в текущей реализации мы словим лишь проблему того, что тесты в 5 минут не прогонятся, а значит мы заставим команду ждать отчет где-то 30 минут точно.
Свой подход в подобной организации инфраструктуры мы пропилотировали еще в ноябре 2016 года. И до тех пор, пока не убедились в стабильности этого решения и его гибкости — публично нигде и не рассказывали. Поэтому, на момент нашей реализации — selenoid-а еще не было.
Я сравнивала работу selenoid-а с тем, как инфра организована у нас. Могу лишь сказать, что оба этих решения не конкурируют друг с другом с точки зрения функциональности. Потому что они решают немного разные задачи. И нам ничего не мешает на наш кластер с Apache Mesos прикрутить Selenoid, но тогда мы все-равно столкнемся с теми же проблемами, которые обозначены в статье с Service Discovery.
Также selenoid не решает задачу, обозначенную в самом начале статьи. Приведу в примерах:
Когда поднимаешь на хосте selenoid, то необходимо самостоятельно вычислять, а сколько контейнеров потянет этот хост. Причем важно понимать, что для контейнера, запускаемом в debug-режиме, конфигурация будет отличаться. Например, если тесты мы можем прогонять на ноде в 512 мб RAM, то когда мы захотим запускать тесты в debug-режиме, исполнение тестов значительно замедлится. Потому что для debug-режима используется image с vnc-сервером, для производительной работы которого необходима конфигурация контейнера как минимум в 750 мб. У selenoid-а нет возможности задавать различные конфигурации контейнерам на одном хосте. То есть, если мы захотим запустить грид в debug-режиме, то придется менять конфигурационные настройки хостов. Это уже выглядит каким-то костылем.
Когда у тебя много хостов, то задача настройки selenoid-а сводится к тому, что каждый этот хост надо законфигурить.Это много времени. И не достаточно гибко.
Если хосты разного размера, то значит на каждом хосте может подниматься грид с каким-то определенным количеством нод. Например, если у меня один хост позволяет поднять только 10 нод, а остальные 15, то когда у меня запустится проект с потребностью в 15 нод — хост, законфигуренный под 10 нод, будет простаивать. Это не оптимальное использование существующих ресурсов.
И наконец, каждый раз когда вы будете конфигурить хост, вам придется делать либо разного размера контейнеры, чтобы по-максимуму заиспользовать ресурсы хоста, либо какую-то часть ресурсов — просто не использовать. Это тоже не оптимально. В нашей же схеме mesos решает вопрос оптимального использования ресурсов в кластере.
Обьясню: один проект у вас исполняется в три потока на одном гриде, но на этом хосте поднят грид в 10 нод. То есть 7 нод свободны. И в тот же промежуток времени нам надо запустить тесты другого проекта, для которого нужно 7 нод, но с другим типом браузера и другой версией. Нам придется тесты запускать на другом гриде, где будет нужная конфигурация грида. А те 7 нод так и будут простаивать.
Если у нас трехпоточный тест, то получится 3 параллельно выполняющихся потока с тестами. Т.е. поднимаются 3 сессии с драйвером браузера, которые поднимают браузер и выполняют тесты. Это реализуется на уровне test runner-а. Мы у себя реализовали такую логику, что runner-ы создаются по количеству тест-сьюитов в проекте и распараллеливаются. Это мотивирует тестировщиков более граммотно организовывать структуру тестового проекта, а также стараться в тест-сьюит группировать тесты по фичам. Таким образом, у нас не бывает ситуации, когда в проекте всего 3 тест-сьюита, и они выполняются долго из-за того, что очень много тестов внутри каждого из них. Сделали мы это с помощью самописного gradle plugin для cucumber.
В вашем случае работает все верно =) Когда маленький проект, и при этом нет потребности встраивать запуск тестов в continuous delivery — то можно и локально запускать.
Docker-compose пробовали. С ним на самом деле те же проблемы с Service Discovery, если вы пытаетесь с помощью Swarm поднять Selenium Grid в multimachine-режиме. Там есть дополнительные сложности с Overlay Network. Поднять на существующей инфраструктуре с Mesos получилось проще.
Мы изначально попробовали пойти этим путем. Но тут есть нюансы:
PhantomJS не все поведенческие кейсы отлавливает, и после такого автотестирования, часть кейсов остается для ручного тестирования. В итоге эта не тот идеальный мир, к которому мы стремились бы, когда весь регресс полностью автоматизирован.
с его помощью нельзя протестировать кроссбраузерность. Для Банка это очень важно. С использованием selenium grid в docker мы можем протестировать в большинстве популярных браузерах, кроме IE (пока).
У нас достаточно быстро прогоняются тесты. Перед каждым запуском создается новый хаб и нужные ноды, а после прохождения — уничтожаются. Поэтому пока не сталкивались с отказами хаба. И даже если это станет действительно проблемой, можно так же динамически создавать дополнительные хабы для проекта с тестами. Более вероятен сценарий, когда по каким-то причинам отваливаются вычислительные ноды. Но это решается на уровне Apache Mesos и Marathon.
Для конкретного проекта поднимается свой единственный selenium grid. Поэтому хаб — один. А вот количество нод — это динамический параметр, который вычисляется в зависимости от количества тест-сьюитов в проекте. В статье указан пример для cucumber-проектов, когда параметр nodes_count рассчитывается bash-скриптом, и этот параметр мы передаем плейбуку перед созданием самого selenium grid-а для проекта. То есть для каких-то проектов это значение может равно 3, а для других — 15.
Так как все проекты, которые мы тестируем, не обладают огромными количествами тестов, поэтому нам хватает одного грида. Изначально, задачи выбора конкретного хаба для проекта не было, и думаю, если будет, то тут можно будет легко подключить selenoid. Ведь он заточен именно под работу с несколькими хабами для проекта.
Пока планируем оффлайн-конфу, с онлайн-включением тех докладчиков, которые не смогут приехать.
Также прорабатываем план Б, который включает в себя как перенос конференции, так и полный переход в онлайн. Будем смотреть по ситуации, какой вариант для наших участников будет лучше.
Не, на codeFest не получается попасть. А можно ссылку на ваш доклад?
По поводу того, что тесты пишут все: тут как команда договорится. Как правило во всех командах аналитики как минимум могут собрать тест-кейсы из готовых шагов, но при этом новые шаги разрабатывать вообще не умеют. Чаще всего, чтоб требования не писать в отдельной доке — описывают уже тестами.
Java-разработчики не любят "программировать на русском языке". Просто это и программированием сложно назвать =).
Но когда команда нуждается в помощи из-за загруженности тестировщика, то проблем не возникало и писали тесты на ура.
Пару раз даже запускали команды без обучения тестировщика и вообще без тестировщика, так как того еще не смогли найти. И в команде автотесты писали сами разработчики. Реже всего привлекаются для этой задачи front-разработчики. Ибо js. И больше времени коммьюнити потом тратит, чтоб им объяснить и научить.
А как вы решаете проблему с тем, что к автоматизатору может случиться большой поток запросов от тестировщиков?
Приоритеты, очередь? Как это может повлиять на регрессию? Что случается в ситуации, когда автотесты сломались и регрессия из-за этого застопорилась?
Один из примеров — старт нового продукта. Как правило, это SPA-приложение, который практически не зависим от других подобных продуктов. Пересекаться они могут только, когда происходит изменение общебанковских сервисов, которые могут затронуть много систем, но это прям исключение из правил. И такие сервисы как правило покрывают тестами, чтоб сберечь обратную совместимость.
Поэтому, первые user story могут выглядеть вообще в стиле "Отобразить кнопку для такой-то категории клиентов". При условии, что все тесты на api пишутся на уровне unit — и e2e-тестов самими разработчиками, со стороны UI нужно выполнить тесты на поведение и интеграцию UI с API. И их опять же оказывается не так много, потому что все возможные логические и алгоритмические проверки для UI-компонент тоже зашиты в модульные тесты на UI, и пишутся фронт-разработчиком.
Багрепорты у нас заводятся тестировщиком, как тикеты в jira. А чаще всего не заводятся — а сразу же правятся разработчиком после приемочного тестирования. Только если баг не критичный, то заводится. Но вопрос приоритетности/критичности принимается совместно командой.
Я постаралась акцентировать внимание в конце статьи как раз на том, что заниматься разработкой тестового фреймворка тоже должна команда. А не выделенные люди.
И у нас, если тестировщик сталкивается со сложной задачей, где его навыков не хватает — реализацией занимается бекенд-разработчик из команды. Чаще всего они работают с тестировщиком в паре, за счет чего также происходит и передача навыков и та самая "прокачка" тестировщика.
По поводу обучения:
Когда мы только пилотировали этот процесс — разработчики автотестов как раз и занимались обучением тестировщиков. Затем мы провели эксперимент и обучение провел java-разработчик, и оно никоим образом в своем качестве не пострадало.
Сейчас у нас обучение проводят уже сами "прокачавшиеся" тестировщики.
А зачем вы сделали фреймворк с технологиями, которые сильно отличались от того, с чем работали ваши разработчики? Наверное, потому что эти разработчики не участвовали в разработке этого фреймворка? Я понимаю, что на SAS, наверное автотесты писать бы не стали, но наверняка у ваших коллег опыт был/есть не только с этой платформой?
Для нас это было проблемой, потому что стоимость разработчика автотестов не маленькая. И естественно PO заинтересован по-максимуму использовать потраченные средства.
Если бы разработчик автотестов начал бы это свободное время тратить каким-либо другим образом на пользу команде/продукту, то наверное, его незанятость не так сильно бы бросалась в глаза.
И если недозагруженность сильная и регулярная — это повод задуматься.
А еще у нас была пара автотестеров, которые оказались недовольны своей незагруженностью и просили у меня дополнительные задачи.
Для нас это было проблемой, потому что стоимость разработчика автотестов не маленькая. И естественно PO заинтересован по-максимуму использовать потраченные средства.
Если бы разработчик автотестов начал бы это свободное время тратить каким-либо другим образом на пользу команде/продукту, то наверное, его незанятость не так сильно бы бросалась в глаза.
И если недозагруженность сильная и регулярная — это повод задуматься.
А еще у нас была пара автотестеров, которые оказались недовольны своей незагруженностью и просили у меня дополнительные задачи.
Для тестировщика нет разницы писать тесты в системе тест-менеджмента, типа HP ALM, куда они раньше тест-кейсы заводили; либо же эти тест-кейсы сразу как автотесты записывать. Библиотека реализована таким образом, что при ее регулярном использовании ты запоминаешь все ее шаги на память (их чуть больше 60), и собираешь тест-кейсы как в конструкторе. Как показал опыт, разработчик внутри команды привлекается редко, лишь тогда, когда тестировщик сталкивается с чем-то непонятным/незнакомым. Типа: реализовать шаги для тестирования интеграции с thrift-сервисом. Как правило, таких временных затрат за месяц набегает не больше 8 часов. Если сравнивать стоимость разработчика автотестов — и стоимость тестировщика, то в этом случае продукт получает экономию размером в еще один оклад тестировщика.
Согласно скрам-гайду — команда, которая делает продукт, должна работать вместе. А не отдельными функциональными группами. Потому что, когда человек не является частью команды ответственной за продукт — качество его работы для этого продукта и эффективность будет сильно страдать.
Эффекта новизны давно уже нет, так как пилотировали подход мы в 2016 году. А в 2017 процесс приобрел массовый характер. Из того, что я наблюдаю — у тестировщиков сформировалось свое коммьюнити, где они друг другу помогают в решении нестандартных проблем. К примеру, если кому-то нужен какой-то определенный шаг для автотеста, закидывается просьба в чат в slack, где либо находится владелец такого шага, либо коллега, готовый поделиться своим опытом.
Минусы статического грида я уже описала в статье. Получается, как минимум в статике мы не сможем поднять все нужные нам конфигурации нод. А если вспомнить о том, как много мы ловили проблем именно из-за нестабильности хаба и нод в статическом состоянии, то текущая концепция on-demand полечила все наши боли по этому поводу.
По поводу проблемы нехватки ресурсов. У Marathon есть одна особенность, когда он не может задеплоить контейнер из-за нехватки места, то задача висит в статусе ожидания, пока не появится место. А нам же ничего не мешает запустить тесты на том количестве нод, места для поднятия которых хватило.
То есть, отправили запрос в marathon на поднятие грида в 20 нод, а место у нас есть только для 5ти. Грид соберется и тесты запустятся на этих 5ти нодах в в параллельном режиме, все остальные тесты будут висеть в очереди на хабе. Как только у нас будет освободождаться место в кластере, то остальные ноды начинаются доподниматься и количество параллельных потоков увеличивается.
Также есть защита от "дурака", встроенная в сам фреймворк с тестами. Так как все наши приложения — это single page приложения, то нам сложно представить для такого приложения тестов в количестве больше 100. Поэтому устанавливаем ограничение сверху по количеству потоков, который проект может сгенерировать.
Ну а так как у нас еще не было проектов с 400+ тестов, то и конкретной проблемы еще не возникало. Как мне видится, в текущей реализации мы словим лишь проблему того, что тесты в 5 минут не прогонятся, а значит мы заставим команду ждать отчет где-то 30 минут точно.
Свой подход в подобной организации инфраструктуры мы пропилотировали еще в ноябре 2016 года. И до тех пор, пока не убедились в стабильности этого решения и его гибкости — публично нигде и не рассказывали. Поэтому, на момент нашей реализации — selenoid-а еще не было.
Я сравнивала работу selenoid-а с тем, как инфра организована у нас. Могу лишь сказать, что оба этих решения не конкурируют друг с другом с точки зрения функциональности. Потому что они решают немного разные задачи. И нам ничего не мешает на наш кластер с Apache Mesos прикрутить Selenoid, но тогда мы все-равно столкнемся с теми же проблемами, которые обозначены в статье с Service Discovery.
Также selenoid не решает задачу, обозначенную в самом начале статьи. Приведу в примерах:
Обьясню: один проект у вас исполняется в три потока на одном гриде, но на этом хосте поднят грид в 10 нод. То есть 7 нод свободны. И в тот же промежуток времени нам надо запустить тесты другого проекта, для которого нужно 7 нод, но с другим типом браузера и другой версией. Нам придется тесты запускать на другом гриде, где будет нужная конфигурация грида. А те 7 нод так и будут простаивать.
Надеюсь достаточно понятно объяснила.
Если у нас трехпоточный тест, то получится 3 параллельно выполняющихся потока с тестами. Т.е. поднимаются 3 сессии с драйвером браузера, которые поднимают браузер и выполняют тесты. Это реализуется на уровне test runner-а. Мы у себя реализовали такую логику, что runner-ы создаются по количеству тест-сьюитов в проекте и распараллеливаются. Это мотивирует тестировщиков более граммотно организовывать структуру тестового проекта, а также стараться в тест-сьюит группировать тесты по фичам. Таким образом, у нас не бывает ситуации, когда в проекте всего 3 тест-сьюита, и они выполняются долго из-за того, что очень много тестов внутри каждого из них. Сделали мы это с помощью самописного gradle plugin для cucumber.
В вашем случае работает все верно =) Когда маленький проект, и при этом нет потребности встраивать запуск тестов в continuous delivery — то можно и локально запускать.
Docker-compose пробовали. С ним на самом деле те же проблемы с Service Discovery, если вы пытаетесь с помощью Swarm поднять Selenium Grid в multimachine-режиме. Там есть дополнительные сложности с Overlay Network. Поднять на существующей инфраструктуре с Mesos получилось проще.
Мы изначально попробовали пойти этим путем. Но тут есть нюансы: