[Тестирование IT-систем, Big Data, Исследования и прогнозы в IT] Как сократить издержки на автотестах
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Автотесты — модная, но довольно затратная история. Автоматизаторы стоят дороже, чем ручные тестировщики, а сами автотесты требуют больше времени на разработку, причем разрабатывается не функционал продукта, а его проверка, которая окупается не явно и не сразу. Требует затрат и поддержка автотестов. Однако каждую из этих статей расходов можно минимизировать, сделав автотестирование намного эффективнее.
Меня зовут Мария Снопок, я менеджер направления автоматизации в Отделе тестирования Департамента разработки и сопровождения продуктов больших данных 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%, чтобы выпускать релизы как можно чаще, но при этом не покрывать автотестами проекты, где ручное тестирование по-прежнему выгоднее.
===========
Источник:
habr.com
===========
Похожие новости:
- [Kotlin] Опыт оптимизации вычислений через динамическую генерацию байт-кода JVM
- [Разработка игр, Дизайн игр, Игры и игровые приставки] Data-driven подход к разработке контента: как мы создаем роботов в War Robots
- [Анализ и проектирование систем] Некоторые мысли о том, что такое автоматизированная информационная система (АИС)
- [Исследования и прогнозы в IT, Производство и разработка электроники, Электроника для начинающих] Исследование рынка разработки электроники за 2019 год
- [Высокая производительность, Производство и разработка электроники, Процессоры] Графический процессор Intel Xe-HP в исполнении из четырех плиток развивает производительность до 42 терафлопс
- [Производство и разработка электроники] Исследователями Samsung открыт новый материал для производства полупроводников
- [Киберпанк, Научно-популярное, Биотехнологии, Медгаджеты, Будущее здесь] Российские учёные создают устройство, которое позволит видеть кожей
- [Big Data, Data Engineering] Как BigQuery от Google демократизировал анализ данных. Часть 2 (перевод)
- [Big Data, Машинное обучение, Статистика в IT, Искусственный интеллект, Data Engineering] Обзор Gartner MQ 2020: Платформы Машинного Обучения и Искусственного Интеллекта
- [Схемотехника, Производство и разработка электроники, История IT, Процессоры] Крохотные генераторы подкачки заряда в процессоре 8086, создающие отрицательное напряжение (перевод)
Теги для поиска: #_testirovanie_itsistem (Тестирование IT-систем), #_big_data, #_issledovanija_i_prognozy_v_it (Исследования и прогнозы в IT), #_avtotesty (автотесты), #_optimizatsija (оптимизация), #_razrabotka (разработка), #_smoke_tests, #_endtoend, #_atribut_dataqa (атрибут data-qa), #_detalizatsija (детализация), #_avtomatizatsija (автоматизация), #_vetvlenie (ветвление), #_testirovschiki (тестировщики), #_sinhronizatsija (синхронизация), #_avtomatizator (автоматизатор), #_blog_kompanii_x5_retail_group (
Блог компании X5 Retail Group
), #_testirovanie_itsistem (
Тестирование IT-систем
), #_big_data, #_issledovanija_i_prognozy_v_it (
Исследования и прогнозы в IT
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:05
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Автотесты — модная, но довольно затратная история. Автоматизаторы стоят дороже, чем ручные тестировщики, а сами автотесты требуют больше времени на разработку, причем разрабатывается не функционал продукта, а его проверка, которая окупается не явно и не сразу. Требует затрат и поддержка автотестов. Однако каждую из этих статей расходов можно минимизировать, сделав автотестирование намного эффективнее. Меня зовут Мария Снопок, я менеджер направления автоматизации в Отделе тестирования Департамента разработки и сопровождения продуктов больших данных 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%, чтобы выпускать релизы как можно чаще, но при этом не покрывать автотестами проекты, где ручное тестирование по-прежнему выгоднее. =========== Источник: habr.com =========== Похожие новости:
Блог компании X5 Retail Group ), #_testirovanie_itsistem ( Тестирование IT-систем ), #_big_data, #_issledovanija_i_prognozy_v_it ( Исследования и прогнозы в IT ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:05
Часовой пояс: UTC + 5