Автотесты — модная, но довольно затратная история. Автоматизаторы стоят дороже, чем ручные тестировщики, а сами автотесты требуют больше времени на разработку, причем разрабатывается не функционал продукта, а его проверка, которая окупается не явно и не сразу. Требует затрат и поддержка автотестов. Однако каждую из этих статей расходов можно минимизировать, сделав автотестирование намного эффективнее.
Меня зовут Мария Снопок, я менеджер направления автоматизации в Отделе тестирования Департамента разработки и сопровождения продуктов больших данных X5 Retail Group. В этой статье я расскажу о нашем опыте внедрения автотестов и сокращении связанных с ними издержек. Надеюсь, эта информация окажется полезной для команд, которые сталкиваются с трудностями при переходе на автоматизированное тестирование.
До появления направления автоматизации я работала тест-менеджером в одном из наших продуктов. Когда там сформировалась довольно большая тестовая модель, мы стали распределять пул регрессионных тестов на всю команду разработки – уж если она отвечает за релиз, значит, она же и тестирует. Такой командный регресс решал следующие задачи:
Но это было дорого, потому что тесты выполняли дорогостоящие специалисты — разработчики и аналитики, и мы начали двигаться в сторону автоматизации.
Первыми пошли smoke-тесты — простые проверки, позволяющие убедиться, что страницы корректно открываются, загружаются, не падают, и весь базовый функционал доступен (пока без проверки логики и значений).
Затем мы автоматизировали положительные end-to-end сценарии. Этот шаг принес максимум пользы: тесты позволяли убедиться, что основные бизнес-процессы продукта работоспособны, даже если были ошибки в негативных, альтернативных и второстепенных сценариях работы.
И наконец добрались до автоматизации расширенных проверок регресса и альтернативных сценариев.
На каждом из этих этапов мы сталкивались с целым рядом трудностей, которые серьезно замедляли и осложняли весь процесс. Какие практические решения помогли нам ускорить и облегчить работу автоматизаторов?
Разработчикам и тестировщикам-автоматизаторам нужно заранее договориться о правилах именования элементов HTML для последующего использования их в качестве локаторов в автотестах. Желательно на всех продуктах иметь единый формат. Мы выработали требования, позволяющие понимать, как именовать атрибуты, еще до того, как фича будет передана в разработку; это понимание есть и на стороне разработчиков, и на стороне тестировщиков. Мы договорились, что каждому видимому html-элементу присваивается кастомный атрибут data-qa, по которому тестировщик будет его искать. Атрибут именуется по следующему шаблону:
[имя экрана][имя формы/таблицы/виджета][имя элемента]
Пример:
data-qa=«plu-list_filter-popover_search-input»
data-qa=”common_toolbar_prev-state"
Такой атрибут легко выделить просто на основании документации и макета, и все знают, каким должно быть его значение. Когда разработчик берет задачу в работу, он по этим правилам присваивает атрибуты data-qa всем видимым элементам страницы – заголовкам, кнопкам, ссылкам, селекторам, строкам и столбцам таблиц и пр. В результате тестировщик может начать писать автотесты ещё в процессе разработки фичи, основываясь только на макет и документацию, потому что уже знает, как будут названы атрибуты.
Внедрение тестовых атрибутов позволило нам снизить затраты на разработку и поддержку автотестов в среднем на 23% в сравнении с предыдущим периодом за счет снижения расходов на актуализацию тестов и локализацию элементов для автотестов.
Ручные тестировщики и автоматизаторы живут в разных вселенных. Ручные нацелены на то, чтобы одним сценарием проверить несколько разных расположенных поблизости объектов теста. Автоматизаторы, напротив, стремятся все структурировать и в рамках одного теста проверять только однотипные объекты. По этой причине ручные тесты не всегда просто автоматизировать. Когда мы получили ручные кейсы для автоматизации, то столкнулись с рядом проблем, не позволяющих нам слово в слово автоматизировать полученные сценарии, потому что они были написаны для удобного выполнения живым человеком.
Если автоматизатор глубоко погружен в продукт, ему не нужны «ручные» кейсы, он сам может написать себе сценарий для автоматизации. Если же он приходит в продукт «со стороны» (у нас в Департаменте помимо тестировщиков в командах также есть тестирование как выделенный сервис), а там уже есть тестовая модель и сценарии, подготовленные ручными тестировщиками, у вас может возникнуть соблазн поручить ему писать автотесты на основе этих «ручных» тест-кейсов.
Не стоит этому поддаваться: максимум, для чего автоматизатор может использовать ручные тест-кейсы, – только чтобы понять, как устроена система с точки зрения пользователя.
Соответственно, надо изначально готовить ручные тесты так, чтобы их можно было автоматизировать, а для этого разобраться с распространенными проблемами.
Проблема 1: упрощение ручных кейсов.
Решение: детализация кейсов.
Представим себе описание ручного кейса:
Это плохой сценарий для автоматизации, потому что в нем не указано, что именно надо открыть, какими именно данными заполнить, что именно мы ожидаем увидеть и в каких полях это посмотреть. Инструкции «убедитесь, что версия успешно создана» для автоматизации недостаточно — машине нужны конкретные критерии, по которым можно убедиться в успешности действия.
Проблема 2: ветвление кейса.
Решение: кейс должен иметь только линейный сценарий.
В ручных кейсах часто фигурируют конструкции с «или». Например: «откройте версию пересмотра 184 под пользователем 1 или 2». Для автоматизации это недопустимо, пользователь должен быть четко указан. Союзов «или» надо избегать.
Проблема 3: неактуальность кейса.
Решение: проверять кейсы перед передачей на автоматизацию.
Для нас это самая большая боль: если функционал часто меняется, тестировщики не успевают актуализировать тест-кейсы. Но если на неактуальный кейс натыкается ручной тестировщик, ему не составит труда быстро подправить сценарий. У автоматизатора, особенно если он не погружен в продукт, так не получится: он просто не поймет, почему кейс работает не так, и воспримет это как баг теста. Потратит кучу времени на разработку, после чего выяснится, что проверяемый функционал давно выпилен, а сценарий неактуален. Поэтому все сценарии для автоматизации должны проверяться на актуальность.
Проблема 4: недостаточно предусловий.
Решение: полный стек вспомогательных данных для выполнения кейса.
У ручных тестировщиков замыливается глаз, в результате чего при описании предварительных условий они упускают некоторые нюансы, очевидные им, но неочевидные автоматизаторам, не так хорошо знакомым с продуктом. Например, они пишут: «открыть страницу с рассчитанным наполнением». Они знают, что для расчета этого наполнения надо запустить расчетный скрипт, а автоматизатор, в первый раз видящий проект, решит, что надо брать что-то уже рассчитанное.
Вывод: в предусловиях надо писать исчерпывающий перечень действий, которые необходимо выполнить перед запуском теста.
Проблема 5: множество проверок в рамках одного сценария.
Решение: на один сценарий не больше трех проверок (исключение – затратные и сложновоспроизводимые сценарии).
У ручных тестировщиков очень часто возникает желание сэкономить на кейсах, особенно когда они тяжелые, и проверить за один сценарий как можно больше, впихнув в него с десяток тестов. Этого нельзя допускать, потому как и в ручном, и в автоматизированном тестировании такой подход порождает одну и ту же проблему: первая проверка не прошла, и все остальные считаются не пройденными или вообще не запускаются в случае автоматизации. Поэтому в сценариях автотестов допустимо от 1 до 3 проверок. Исключения — действительно тяжелые сценарии, требующие временных затрат на предрасчеты, а также сложновоспроизводимые сценарии. Здесь можно поступиться правилом, хотя лучше так не делать.
Проблема 6: дублирующие проверки.
Решение: не нужно многократно автоматизировать один и тот же функционал.
Если у нас есть один и тот же функционал на нескольких страницах, например, стандартный фильтр, то нет смысла при регресс-тестировании проверять его везде, достаточно посмотреть в одном месте (если, конечно, речь не идет о новой фиче). Ручные тестировщики пишут сценарии и проверяют подобные вещи на каждой странице – просто потому, что они рассматривают каждую страницу по отдельности, не вдаваясь в вопросы ее внутреннего строения. Но автоматизаторы должны понимать, что многократное тестирование одного и того же – это потеря времени и ресурсов, и обнаружить подобные ситуации им достаточно легко.
Решение вышеперечисленных проблем позволило нам снизить затраты на разработку автотестов на 16%.
В нашем Департаменте больших данных, где разрабатывается 13 продуктов, есть две группы автоматизаторов:
Стрим-автоматизаторы изначально не так глубоко погружены в продукт, и раньше они не посещали ежедневные встречи команд, потому что это отнимало бы у них слишком много времени. Однажды такой подход подвел нас: мы случайно узнали из сторонних источников, что одна команда собралась рефакторить свой продукт (разбивать монолит на микросервисы), из-за чего часть тестов, которые мы написали, отправляется в архив. Было очень больно.
Чтобы не допускать подобного в будущем, приняли решение, что хотя бы раз в неделю автоматизатор из стрима будет приходить на встречи команды разработки, чтобы быть в курсе происходящего с продуктом.
Также мы договорились, что автоматизируются тесты только для того функционала, который готов к продакшну и не подвергается частым изменениям (регресс). Мы должны быть уверены, что хотя бы в ближайшие три месяца с ним не случится рефакторинг или серьезная переработка, иначе автоматизаторы просто не успеют с тестами.
Снижение издержек по результатам внедрения этих мер рассчитать сложнее. Мы взяли за основу время на разработку автотестов, утративших свою ценность в связи с планируемым переходом части функционала в микросервисы. Если бы мы знали об этом переходе заранее, то не покрывали бы автотестами изменяемый функционал. Итого потеря (она же потенциальная экономия) – 7%.
Автоматизаторов тестирования на рынке труда мало, особенно хороших, и мы их активно ищем. Также мы активно апгрейдим уже имеющихся ручных тестировщиков, у которых есть желание и базовые представления об автоматизации. Таких людей мы в первую очередь отправляем на курсы по языку программирования, потому что нам нужны полноценные автоматизаторы и полноценные автотесты, а от рекордеров, на наш взгляд, больше минусов, чем плюсов.
Параллельно с изучением языка программирования человек учится писать правильные, структурированные сценарии без проблем из пункта 2, читать и анализировать результаты отчетов автотестов, править мелкие ошибки в локаторах, простых методах, затем поддерживать готовые тесты, а уж потом писать свои. Все развитие проходит при поддержке опытных коллег из стрим-сервиса. В перспективе они могут участвовать в доработке фреймворка: у нас есть своя библиотека, масштабируемая на все проекты, ее можно совершенствовать, добавляя что-то свое.
Это направление снижения затрат у нас находится в стадии становления, поэтому подсчитывать экономию пока рано, но есть все основания полагать, что обучение кадров поможет существенно сократить текущие издержки. А заодно даст нашим ручным тестировщикам возможность развиваться.
Сейчас мы автоматизировали примерно 30% тестов на пяти продуктах, что привело к сокращению времени регресс-тестирования в 2 раза.
Это годный результат, поскольку время для нас имеет большое значение: мы не можем тестировать бесконечно долго и не можем отдавать продукт без проверок; автоматизация же позволяет обеспечить необходимый объем проверок продукта в оптимальные сроки. В дальнейшем мы планируем довести процент автотестов до 80-90%, чтобы выпускать релизы как можно чаще, но при этом не покрывать автотестами проекты, где ручное тестирование по-прежнему выгоднее.
Меня зовут Мария Снопок, я менеджер направления автоматизации в Отделе тестирования Департамента разработки и сопровождения продуктов больших данных 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 продуктов, есть две группы автоматизаторов:
- автоматизаторы непосредственно в продуктовых командах;
- стрим-сервис автоматизации вне продуктовых команд, занимающийся разработкой фреймворка и общих компонентов и работающий по заявкам от продуктов с уже готовыми функциональными тестами.
Стрим-автоматизаторы изначально не так глубоко погружены в продукт, и раньше они не посещали ежедневные встречи команд, потому что это отнимало бы у них слишком много времени. Однажды такой подход подвел нас: мы случайно узнали из сторонних источников, что одна команда собралась рефакторить свой продукт (разбивать монолит на микросервисы), из-за чего часть тестов, которые мы написали, отправляется в архив. Было очень больно.
Чтобы не допускать подобного в будущем, приняли решение, что хотя бы раз в неделю автоматизатор из стрима будет приходить на встречи команды разработки, чтобы быть в курсе происходящего с продуктом.
Также мы договорились, что автоматизируются тесты только для того функционала, который готов к продакшну и не подвергается частым изменениям (регресс). Мы должны быть уверены, что хотя бы в ближайшие три месяца с ним не случится рефакторинг или серьезная переработка, иначе автоматизаторы просто не успеют с тестами.
Снижение издержек по результатам внедрения этих мер рассчитать сложнее. Мы взяли за основу время на разработку автотестов, утративших свою ценность в связи с планируемым переходом части функционала в микросервисы. Если бы мы знали об этом переходе заранее, то не покрывали бы автотестами изменяемый функционал. Итого потеря (она же потенциальная экономия) – 7%.
4. Апгрейд ручного тестировщика до автоматизатора
Автоматизаторов тестирования на рынке труда мало, особенно хороших, и мы их активно ищем. Также мы активно апгрейдим уже имеющихся ручных тестировщиков, у которых есть желание и базовые представления об автоматизации. Таких людей мы в первую очередь отправляем на курсы по языку программирования, потому что нам нужны полноценные автоматизаторы и полноценные автотесты, а от рекордеров, на наш взгляд, больше минусов, чем плюсов.
Параллельно с изучением языка программирования человек учится писать правильные, структурированные сценарии без проблем из пункта 2, читать и анализировать результаты отчетов автотестов, править мелкие ошибки в локаторах, простых методах, затем поддерживать готовые тесты, а уж потом писать свои. Все развитие проходит при поддержке опытных коллег из стрим-сервиса. В перспективе они могут участвовать в доработке фреймворка: у нас есть своя библиотека, масштабируемая на все проекты, ее можно совершенствовать, добавляя что-то свое.
Это направление снижения затрат у нас находится в стадии становления, поэтому подсчитывать экономию пока рано, но есть все основания полагать, что обучение кадров поможет существенно сократить текущие издержки. А заодно даст нашим ручным тестировщикам возможность развиваться.
Итог
Сейчас мы автоматизировали примерно 30% тестов на пяти продуктах, что привело к сокращению времени регресс-тестирования в 2 раза.
Это годный результат, поскольку время для нас имеет большое значение: мы не можем тестировать бесконечно долго и не можем отдавать продукт без проверок; автоматизация же позволяет обеспечить необходимый объем проверок продукта в оптимальные сроки. В дальнейшем мы планируем довести процент автотестов до 80-90%, чтобы выпускать релизы как можно чаще, но при этом не покрывать автотестами проекты, где ручное тестирование по-прежнему выгоднее.
