Как сократить издержки на автотестах

    Автотесты — модная, но довольно затратная история. Автоматизаторы стоят дороже, чем ручные тестировщики, а сами автотесты требуют больше времени на разработку, причем разрабатывается не функционал продукта, а его проверка, которая окупается не явно и не сразу. Требует затрат и поддержка автотестов. Однако каждую из этих статей расходов можно минимизировать, сделав автотестирование намного эффективнее.

    Меня зовут Мария Снопок, я менеджер направления автоматизации в Отделе тестирования Департамента разработки и сопровождения продуктов больших данных X5 Retail Group. В этой статье я расскажу о нашем опыте внедрения автотестов и сокращении связанных с ними издержек. Надеюсь, эта информация окажется полезной для команд, которые сталкиваются с трудностями при переходе на автоматизированное тестирование.



    Как мы пришли к автотестам


    До появления направления автоматизации я работала тест-менеджером в одном из наших продуктов. Когда там сформировалась довольно большая тестовая модель, мы стали распределять пул регрессионных тестов на всю команду разработки – уж если она отвечает за релиз, значит, она же и тестирует. Такой командный регресс решал следующие задачи:

    • разработчики, до того имевшие дело со своими обособленными кусочками функционала, получали возможность увидеть продукт целиком;
    • мы делали регресс быстрее и за счет этого релизились чаще;
    • мы больше не сокращали объем регресса — улучшилось качество.

    Но это было дорого, потому что тесты выполняли дорогостоящие специалисты — разработчики и аналитики, и мы начали двигаться в сторону автоматизации.

    Первыми пошли smoke-тесты — простые проверки, позволяющие убедиться, что страницы корректно открываются, загружаются, не падают, и весь базовый функционал доступен (пока без проверки логики и значений).

    Затем мы автоматизировали положительные end-to-end сценарии. Этот шаг принес максимум пользы: тесты позволяли убедиться, что основные бизнес-процессы продукта работоспособны, даже если были ошибки в негативных, альтернативных и второстепенных сценариях работы.

    И наконец добрались до автоматизации расширенных проверок регресса и альтернативных сценариев.



    На каждом из этих этапов мы сталкивались с целым рядом трудностей, которые серьезно замедляли и осложняли весь процесс. Какие практические решения помогли нам ускорить и облегчить работу автоматизаторов?

    Четыре направления сокращения издержек на автотестах


    1. Договариваемся о форматах тестовых атрибутов на берегу


    Разработчикам и тестировщикам-автоматизаторам нужно заранее договориться о правилах именования элементов HTML для последующего использования их в качестве локаторов в автотестах. Желательно на всех продуктах иметь единый формат. Мы выработали требования, позволяющие понимать, как именовать атрибуты, еще до того, как фича будет передана в разработку; это понимание есть и на стороне разработчиков, и на стороне тестировщиков. Мы договорились, что каждому видимому html-элементу присваивается кастомный атрибут data-qa, по которому тестировщик будет его искать. Атрибут именуется по следующему шаблону:

    [имя экрана][имя формы/таблицы/виджета][имя элемента]

    Пример:
    data-qa=«plu-list_filter-popover_search-input»
    data-qa=”common_toolbar_prev-state"


    Такой атрибут легко выделить просто на основании документации и макета, и все знают, каким должно быть его значение. Когда разработчик берет задачу в работу, он по этим правилам присваивает атрибуты data-qa всем видимым элементам страницы – заголовкам, кнопкам, ссылкам, селекторам, строкам и столбцам таблиц и пр. В результате тестировщик может начать писать автотесты ещё в процессе разработки фичи, основываясь только на макет и документацию, потому что уже знает, как будут названы атрибуты.

    Внедрение тестовых атрибутов позволило нам снизить затраты на разработку и поддержку автотестов в среднем на 23% в сравнении с предыдущим периодом за счет снижения расходов на актуализацию тестов и локализацию элементов для автотестов.

    2. Пишем ручные тесты так, чтобы их было легко автоматизировать


    Ручные тестировщики и автоматизаторы живут в разных вселенных. Ручные нацелены на то, чтобы одним сценарием проверить несколько разных расположенных поблизости объектов теста. Автоматизаторы, напротив, стремятся все структурировать и в рамках одного теста проверять только однотипные объекты. По этой причине ручные тесты не всегда просто автоматизировать. Когда мы получили ручные кейсы для автоматизации, то столкнулись с рядом проблем, не позволяющих нам слово в слово автоматизировать полученные сценарии, потому что они были написаны для удобного выполнения живым человеком.

    Если автоматизатор глубоко погружен в продукт, ему не нужны «ручные» кейсы, он сам может написать себе сценарий для автоматизации. Если же он приходит в продукт «со стороны» (у нас в Департаменте помимо тестировщиков в командах также есть тестирование как выделенный сервис), а там уже есть тестовая модель и сценарии, подготовленные ручными тестировщиками, у вас может возникнуть соблазн поручить ему писать автотесты на основе этих «ручных» тест-кейсов.

    Не стоит этому поддаваться: максимум, для чего автоматизатор может использовать ручные тест-кейсы, – только чтобы понять, как устроена система с точки зрения пользователя.
    Соответственно, надо изначально готовить ручные тесты так, чтобы их можно было автоматизировать, а для этого разобраться с распространенными проблемами.

    Проблема 1: упрощение ручных кейсов.

    Решение: детализация кейсов.

    Представим себе описание ручного кейса:

    • откройте страницу списка версий пересмотра
    • нажмите кнопку создания
    • заполните форму
    • нажмите кнопку «создать»
    • убедитесь, что версия пересмотра создана

    Это плохой сценарий для автоматизации, потому что в нем не указано, что именно надо открыть, какими именно данными заполнить, что именно мы ожидаем увидеть и в каких полях это посмотреть. Инструкции «убедитесь, что версия успешно создана» для автоматизации недостаточно — машине нужны конкретные критерии, по которым можно убедиться в успешности действия.

    Проблема 2: ветвление кейса.

    Решение: кейс должен иметь только линейный сценарий.

    В ручных кейсах часто фигурируют конструкции с «или». Например: «откройте версию пересмотра 184 под пользователем 1 или 2». Для автоматизации это недопустимо, пользователь должен быть четко указан. Союзов «или» надо избегать.

    Проблема 3: неактуальность кейса.

    Решение:
    проверять кейсы перед передачей на автоматизацию.

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

    Проблема 4: недостаточно предусловий.

    Решение:
    полный стек вспомогательных данных для выполнения кейса.

    У ручных тестировщиков замыливается глаз, в результате чего при описании предварительных условий они упускают некоторые нюансы, очевидные им, но неочевидные автоматизаторам, не так хорошо знакомым с продуктом. Например, они пишут: «открыть страницу с рассчитанным наполнением». Они знают, что для расчета этого наполнения надо запустить расчетный скрипт, а автоматизатор, в первый раз видящий проект, решит, что надо брать что-то уже рассчитанное.
    Вывод: в предусловиях надо писать исчерпывающий перечень действий, которые необходимо выполнить перед запуском теста.

    Проблема 5: множество проверок в рамках одного сценария.

    Решение:
    на один сценарий не больше трех проверок (исключение – затратные и сложновоспроизводимые сценарии).

    У ручных тестировщиков очень часто возникает желание сэкономить на кейсах, особенно когда они тяжелые, и проверить за один сценарий как можно больше, впихнув в него с десяток тестов. Этого нельзя допускать, потому как и в ручном, и в автоматизированном тестировании такой подход порождает одну и ту же проблему: первая проверка не прошла, и все остальные считаются не пройденными или вообще не запускаются в случае автоматизации. Поэтому в сценариях автотестов допустимо от 1 до 3 проверок. Исключения — действительно тяжелые сценарии, требующие временных затрат на предрасчеты, а также сложновоспроизводимые сценарии. Здесь можно поступиться правилом, хотя лучше так не делать.

    Проблема 6: дублирующие проверки.

    Решение:
    не нужно многократно автоматизировать один и тот же функционал.

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

    Решение вышеперечисленных проблем позволило нам снизить затраты на разработку автотестов на 16%.

    3. Синхронизация с продуктовыми командами по вопросу рефакторинга, редизайна, существенных изменений функционала, чтобы не писать тесты «в стол»


    В нашем Департаменте больших данных, где разрабатывается 13 продуктов, есть две группы автоматизаторов:

    1. автоматизаторы непосредственно в продуктовых командах;
    2. стрим-сервис автоматизации вне продуктовых команд, занимающийся разработкой фреймворка и общих компонентов и работающий по заявкам от продуктов с уже готовыми функциональными тестами.

    Стрим-автоматизаторы изначально не так глубоко погружены в продукт, и раньше они не посещали ежедневные встречи команд, потому что это отнимало бы у них слишком много времени. Однажды такой подход подвел нас: мы случайно узнали из сторонних источников, что одна команда собралась рефакторить свой продукт (разбивать монолит на микросервисы), из-за чего часть тестов, которые мы написали, отправляется в архив. Было очень больно.

    Чтобы не допускать подобного в будущем, приняли решение, что хотя бы раз в неделю автоматизатор из стрима будет приходить на встречи команды разработки, чтобы быть в курсе происходящего с продуктом.

    Также мы договорились, что автоматизируются тесты только для того функционала, который готов к продакшну и не подвергается частым изменениям (регресс). Мы должны быть уверены, что хотя бы в ближайшие три месяца с ним не случится рефакторинг или серьезная переработка, иначе автоматизаторы просто не успеют с тестами.

    Снижение издержек по результатам внедрения этих мер рассчитать сложнее. Мы взяли за основу время на разработку автотестов, утративших свою ценность в связи с планируемым переходом части функционала в микросервисы. Если бы мы знали об этом переходе заранее, то не покрывали бы автотестами изменяемый функционал. Итого потеря (она же потенциальная экономия) – 7%.

    4. Апгрейд ручного тестировщика до автоматизатора


    Автоматизаторов тестирования на рынке труда мало, особенно хороших, и мы их активно ищем. Также мы активно апгрейдим уже имеющихся ручных тестировщиков, у которых есть желание и базовые представления об автоматизации. Таких людей мы в первую очередь отправляем на курсы по языку программирования, потому что нам нужны полноценные автоматизаторы и полноценные автотесты, а от рекордеров, на наш взгляд, больше минусов, чем плюсов.

    Параллельно с изучением языка программирования человек учится писать правильные, структурированные сценарии без проблем из пункта 2, читать и анализировать результаты отчетов автотестов, править мелкие ошибки в локаторах, простых методах, затем поддерживать готовые тесты, а уж потом писать свои. Все развитие проходит при поддержке опытных коллег из стрим-сервиса. В перспективе они могут участвовать в доработке фреймворка: у нас есть своя библиотека, масштабируемая на все проекты, ее можно совершенствовать, добавляя что-то свое.

    Это направление снижения затрат у нас находится в стадии становления, поэтому подсчитывать экономию пока рано, но есть все основания полагать, что обучение кадров поможет существенно сократить текущие издержки. А заодно даст нашим ручным тестировщикам возможность развиваться.

    Итог


    Сейчас мы автоматизировали примерно 30% тестов на пяти продуктах, что привело к сокращению времени регресс-тестирования в 2 раза.

    Это годный результат, поскольку время для нас имеет большое значение: мы не можем тестировать бесконечно долго и не можем отдавать продукт без проверок; автоматизация же позволяет обеспечить необходимый объем проверок продукта в оптимальные сроки. В дальнейшем мы планируем довести процент автотестов до 80-90%, чтобы выпускать релизы как можно чаще, но при этом не покрывать автотестами проекты, где ручное тестирование по-прежнему выгоднее.
    X5 Retail Group
    Все о цифровой трансформации ритейла

    Комментарии 16

      +1
      Вопрос, сколько денег было потрачено и сколько вы зарабатываете/экономите на этом?
      ROI какой?
        0
        Расчетная окупаемость первых тестов – 40-45-й запуск, для нас это 2-3 месяца в зависимости от количества поставок. Но нужно учитывать, что в старт автоматизации вошла и трудоемкая часть – разработка фреймворка.
          0
          Итого, пока что рои отрицательный и вы просто растратили деньги.
          И окупаемости не видно, потому что вам придеться потратить еще деньги на поддержку.

            0
            Конечно, мы учитываем поддержку – тонуть под поддержкой автотестов не лучше, чем тонуть под ручным регрессом. В остальном вы спешите с выводами. Возможно, в одной из следующих статей мы рассмотрим именно ROI.
        +1
        Как сократить издержки на автотестах

        До появления направления автоматизации я работала тест-менеджером в одном из наших продуктов.

        Разработчикам и тестировщикам-автоматизаторам нужно заранее договориться о правилах именования элементов HTML для последующего использования их в качестве локаторов в автотестах.

        Пройдет еще год, а может десять, следующий менеджер вдруг решит подсчитать косты на поддержку и написание новых сценариев.
        Потом этот человек, возможно, почитает о антипаттернах автоматизации и посмотрит на всякие пирамиды тестирования. Далее придет осознание, что все время вы шли не в ту сторону и не надо было автоматизировать e2e сценарии дорогими UI тестами. Запустится пилотный проект по автоматизации регресса API тестами, снова подсчитают косты и удивятся тому, насколько быстро гоняется регресс и сколько времени и денег экономится. Оставят самых адекватных автоматизаторов, а большую часть из 4го пункта под нож.
          0
          При принятии решения об автоматизации UI мы руководствовались спецификой продуктов и анализом дефектов по продукту. Пользы от автоматизации API никто не умаляет, однако гарантировать работоспособность продуктов API-тесты могут только в комплексе с unit-тестами на фронт. Практика автоматизации фронта со стороны разработки на наших продуктах в процессе внедрения. Поэтому с целью максимизации полезности автотестов было принято решение часть регресса и e2e автоматизировать на UI. По поводу ножа – у нас не настолько большая команда автоматизаторов, чтобы так легкомысленно пускать сотрудников в расход)
          0
          Спасибо. Хороший охват.
          На что вы пишете автоматотесты в первую очередь? На регрес или новую функциональность?
            0
            В первую очередь автоматизируем стабильный функционал (регресс), затем новую функциональность.
              0
              Хороший пример.
              А сколько ошибок находят при прогоне регресса?
            0

            А есть метрика отношения времени на разработку фичи ко времени на покрытие её выскоуровневыми тестами?

              +1
              Такой метрики нет, будет повод подумать над ее добавлением, спасибо!
              +1
              Тема про ROI не раскрыта, а хотелось бы. В эту же тему нет упоминания по каким тригерам и какие тесты ранятся. И, следовательно, кто есть бенефициантом этих тестов. Когда дев вливает стрёмную фичу тестировщик может запустить ваши тесты локально или на сиае, чтоб не тестить всё вручную? Он может прочитать репорт и понять чего там было и что поломалось?
              Разработчик может запустить часть автотестов, которые релевантны к его изменениям? Есть тесты, которые являются quality gateway для дев пиаров? Вот это вообще очень важно, т.к. быстрая обратная связь от тестов девелоперу позволяет ему починить проблему сразу не переключая контекст. А на этом экономится не мало его времени и, соответственно, деньги.
              Была ли у вас мысль после покрытия смоук тестов и основного функционала e2e переключить автоматизаторов на написания снапшот тестов во фронте? Компонентные юнит тесты и юнит тесты на утилиты. Их относительно не сложно писать, но зато вы начнёте идти от мороженки к правильной пирамиде.
              Вы анализировали скорость своих тест ранов? Если они занимают много времени, то дев успеет переключить контекст и часть смысла ваших тестов теряется. Как у вас с параллелизацией?
                0
                Эти вопросы не относятся напрямую к теме статьи, поэтому не раскрывались. Автотесты встроены в пайплайн и в зависимости от тестового набора запускаются либо автоматически по принятию MR, либо вручную. У всей команды есть доступ к подробной отчетности в AllureEE, уровни детализации отчетов позволяют понять, что именно поломалось.

                Хорошее замечание, пока у нас нет возможности маппить тесты с затрагиваемой функциональностью (есть маппинг по экранам, но нет по компонентам), но в перспективе мы планируем с этим вопросом разобраться.

                Мы придерживаемся мнения, что unit-тесты – зона ответственности разработчиков. Snapshot-тесты полезны, хотя их поддержка не менее трудоемка, чем поддержка других тестов. Перевернуть мороженку в правильную пирамиду – как раз то, что нам нужно в перспективе, но для начала нужно подружить теорию с реальностью.

                Конечно, мы запускаем тесты параллельно, количество потоков подбирается с учетом минимизации времени на запуск (увеличение количества потоков не всегда дает экономию на запуске).

                  0
                  А в чём трудоёмкость поддержки снапшотов? Берём Jest, настраиваем, за секунд 15 делаем тест, потом разработчик делает изменения, валит тест, понимает, что так и хотел и в одну команду за доли секунды чинит тест обновляя снапшот.

                    0

                    От снэпшотов зависит и отношения к ним. На практике или часто вырождаются в обновление без вникание в того, что изменилось в простыне на сотни, а то и тысячи строк. Или в многочасовые разборы все ли изменения корректны. Поэтому не люблю глубокие html-снэпшоты (для реакт в частности), но команда обычно против неглубоких, потому что для "приличного" покрытия нужно писать тесты на каждый компонент, практически юнит-тесты, а не на уровне целых страниц или крупных компонентов.

                    0
                    А в чём трудоёмкость поддержки снапшотов? Берём Jest, настраиваем, за секунд 15 делаем тест, потом разработчик делает изменения, валит тест, понимает, что так и хотел и в одну команду за доли секунды чинит тест обновляя снапшот.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое