Комментарии 16
Вопрос, сколько денег было потрачено и сколько вы зарабатываете/экономите на этом?
ROI какой?
ROI какой?
Расчетная окупаемость первых тестов – 40-45-й запуск, для нас это 2-3 месяца в зависимости от количества поставок. Но нужно учитывать, что в старт автоматизации вошла и трудоемкая часть – разработка фреймворка.
Как сократить издержки на автотестах
До появления направления автоматизации я работала тест-менеджером в одном из наших продуктов.
Разработчикам и тестировщикам-автоматизаторам нужно заранее договориться о правилах именования элементов HTML для последующего использования их в качестве локаторов в автотестах.
Пройдет еще год, а может десять, следующий менеджер вдруг решит подсчитать косты на поддержку и написание новых сценариев.
Потом этот человек, возможно, почитает о антипаттернах автоматизации и посмотрит на всякие пирамиды тестирования. Далее придет осознание, что все время вы шли не в ту сторону и не надо было автоматизировать e2e сценарии дорогими UI тестами. Запустится пилотный проект по автоматизации регресса API тестами, снова подсчитают косты и удивятся тому, насколько быстро гоняется регресс и сколько времени и денег экономится. Оставят самых адекватных автоматизаторов, а большую часть из 4го пункта под нож.
При принятии решения об автоматизации UI мы руководствовались спецификой продуктов и анализом дефектов по продукту. Пользы от автоматизации API никто не умаляет, однако гарантировать работоспособность продуктов API-тесты могут только в комплексе с unit-тестами на фронт. Практика автоматизации фронта со стороны разработки на наших продуктах в процессе внедрения. Поэтому с целью максимизации полезности автотестов было принято решение часть регресса и e2e автоматизировать на UI. По поводу ножа – у нас не настолько большая команда автоматизаторов, чтобы так легкомысленно пускать сотрудников в расход)
Спасибо. Хороший охват.
На что вы пишете автоматотесты в первую очередь? На регрес или новую функциональность?
На что вы пишете автоматотесты в первую очередь? На регрес или новую функциональность?
А есть метрика отношения времени на разработку фичи ко времени на покрытие её выскоуровневыми тестами?
Тема про ROI не раскрыта, а хотелось бы. В эту же тему нет упоминания по каким тригерам и какие тесты ранятся. И, следовательно, кто есть бенефициантом этих тестов. Когда дев вливает стрёмную фичу тестировщик может запустить ваши тесты локально или на сиае, чтоб не тестить всё вручную? Он может прочитать репорт и понять чего там было и что поломалось?
Разработчик может запустить часть автотестов, которые релевантны к его изменениям? Есть тесты, которые являются quality gateway для дев пиаров? Вот это вообще очень важно, т.к. быстрая обратная связь от тестов девелоперу позволяет ему починить проблему сразу не переключая контекст. А на этом экономится не мало его времени и, соответственно, деньги.
Была ли у вас мысль после покрытия смоук тестов и основного функционала e2e переключить автоматизаторов на написания снапшот тестов во фронте? Компонентные юнит тесты и юнит тесты на утилиты. Их относительно не сложно писать, но зато вы начнёте идти от мороженки к правильной пирамиде.
Вы анализировали скорость своих тест ранов? Если они занимают много времени, то дев успеет переключить контекст и часть смысла ваших тестов теряется. Как у вас с параллелизацией?
Разработчик может запустить часть автотестов, которые релевантны к его изменениям? Есть тесты, которые являются quality gateway для дев пиаров? Вот это вообще очень важно, т.к. быстрая обратная связь от тестов девелоперу позволяет ему починить проблему сразу не переключая контекст. А на этом экономится не мало его времени и, соответственно, деньги.
Была ли у вас мысль после покрытия смоук тестов и основного функционала e2e переключить автоматизаторов на написания снапшот тестов во фронте? Компонентные юнит тесты и юнит тесты на утилиты. Их относительно не сложно писать, но зато вы начнёте идти от мороженки к правильной пирамиде.
Вы анализировали скорость своих тест ранов? Если они занимают много времени, то дев успеет переключить контекст и часть смысла ваших тестов теряется. Как у вас с параллелизацией?
Эти вопросы не относятся напрямую к теме статьи, поэтому не раскрывались. Автотесты встроены в пайплайн и в зависимости от тестового набора запускаются либо автоматически по принятию MR, либо вручную. У всей команды есть доступ к подробной отчетности в AllureEE, уровни детализации отчетов позволяют понять, что именно поломалось.
Хорошее замечание, пока у нас нет возможности маппить тесты с затрагиваемой функциональностью (есть маппинг по экранам, но нет по компонентам), но в перспективе мы планируем с этим вопросом разобраться.
Мы придерживаемся мнения, что unit-тесты – зона ответственности разработчиков. Snapshot-тесты полезны, хотя их поддержка не менее трудоемка, чем поддержка других тестов. Перевернуть мороженку в правильную пирамиду – как раз то, что нам нужно в перспективе, но для начала нужно подружить теорию с реальностью.
Конечно, мы запускаем тесты параллельно, количество потоков подбирается с учетом минимизации времени на запуск (увеличение количества потоков не всегда дает экономию на запуске).
Хорошее замечание, пока у нас нет возможности маппить тесты с затрагиваемой функциональностью (есть маппинг по экранам, но нет по компонентам), но в перспективе мы планируем с этим вопросом разобраться.
Мы придерживаемся мнения, что unit-тесты – зона ответственности разработчиков. Snapshot-тесты полезны, хотя их поддержка не менее трудоемка, чем поддержка других тестов. Перевернуть мороженку в правильную пирамиду – как раз то, что нам нужно в перспективе, но для начала нужно подружить теорию с реальностью.
Конечно, мы запускаем тесты параллельно, количество потоков подбирается с учетом минимизации времени на запуск (увеличение количества потоков не всегда дает экономию на запуске).
А в чём трудоёмкость поддержки снапшотов? Берём Jest, настраиваем, за секунд 15 делаем тест, потом разработчик делает изменения, валит тест, понимает, что так и хотел и в одну команду за доли секунды чинит тест обновляя снапшот.
От снэпшотов зависит и отношения к ним. На практике или часто вырождаются в обновление без вникание в того, что изменилось в простыне на сотни, а то и тысячи строк. Или в многочасовые разборы все ли изменения корректны. Поэтому не люблю глубокие html-снэпшоты (для реакт в частности), но команда обычно против неглубоких, потому что для "приличного" покрытия нужно писать тесты на каждый компонент, практически юнит-тесты, а не на уровне целых страниц или крупных компонентов.
А в чём трудоёмкость поддержки снапшотов? Берём Jest, настраиваем, за секунд 15 делаем тест, потом разработчик делает изменения, валит тест, понимает, что так и хотел и в одну команду за доли секунды чинит тест обновляя снапшот.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как сократить издержки на автотестах