Автоматизация тестирования: подготовка стратегии и подводные камни внедрения
Я работаю в IT больше двенадцати лет, четыре из которых — лидом команды тестировщиков. Как и все, мы пытаемся внедрять автотесты, чтобы ускорить процесс, увеличить тестовое покрытие и вообще облегчить себе жизнь и работу.
Думаю, основанный на опыте нашей команды материал будет полезен тем, кто только начинает выстраивать процесс автоматизации или недоволен тем, что из этого пока получается. Скажу сразу, что не буду вдаваться в технические детали или перечислять конкретные инструменты: это требует индивидуального подхода в зависимости от приложения и конкретной команды. Я же сосредоточусь на общем подходе и стратегии. Поделюсь основными идеями и подводными камнями, с которыми мы уже успели столкнуться, и попробую помочь вам избежать их в будущем. Некоторые вещи кажутся очевидными тем, у кого опыт автоматизации уже есть, но иногда стоит вернуться к истокам и вспомнить простые правила, которые часто забываются со временем. Итак, поехали.
С чего начать формировать стратегию
Думаю, всем доводилось получать сообщения от пользователей о багах, не обнаруженных автотестами. На самом деле, невнимательны бывают и пользователи, и мы с вами не всегда идеально понимаем нюансы бизнеса, для которого разрабатываем продукт, или не можем покрыть все сценарии. Например, был такой случай на одном из тестовых окружений. Тест переходил по ссылке и проверял, чтобы новая страница открывалась, причем только сам факт этого. Однако открытие страницы с надписью «У вас нет прав для просмотра» тоже проходило как успешный сценарий, хотя таковым не являлось. В итоге проблема есть, но тест успешен. В любом случае процесс можно улучшить, и автотесты — мощный инструмент для этого.
Автоматизацию тестирования лучше всего начинать с применения ко всей работе стандартной пирамиды, в основе которой лежат юниты и интеграционные тесты от разработчиков.
Дальше — в зависимости от частоты выполнения того или иного типа тестирования, необходимости и рисков. Поэтому следующими автоматизируют smoke-тесты, затем переходят к функциональным или регрессионным. Потом можно внедрять автоматизированное тестирование на уровне Continuous Delivery, но всему свое время.
Шаг 1. Выбираем функционал для автоматизации
Если уже есть написанные заранее тест-кейсы — это хорошо, на их основе мы и будем строить анализ. Если тест-кейсов нет, что ж, пора их написать.
Обратим внимание на следующие пункты.
Можно ли в принципе автоматизировать те или иные сценарии и целесообразно ли это? Например, запись в базе появится через полчаса-час после добавления, есть ли смысл автотесту ждать этого? В принципе подождать можно, но ускорим ли мы в этом случае процесс тестирования в целом? А ведь обычно в этом и заключена едва ли не основная цель автоматизации. Получается, заменять ручное тестирование в таком процессе нужно, только если мы хотим полностью избавить наших Manual QA от необходимости смотреть в эту сторону.
А если сценарий простой, а проверка разовая, надо ли тратить время на ее автоматизацию? Теоретически да, особенно если клиент требует «автоматизировать абсолютно всё!». Но учтите, что это неизбежно влечет дополнительные расходы. Готовы ли вы к ним в текущем проекте? Может, стоит внимательно посмотреть на нечто более важное?
Наконец, если каждый раз данные для теста нужно тщательно подбирать вручную, есть ли смысл в автоматизации? Для сложных финансовых систем не всегда есть возможность составить универсальный запрос для получения информации. Целесообразно ли в вашем случае вручную формировать данные при каждом запуске автотеста?
Существуют и тесты, где человек быстрее и с большей вероятностью заметит ошибку. Следует ли выстраивать проверки на необходимые ожидания с помощью скриптов?
Окупятся ли ресурсы, потраченные на автоматизацию? В первом приближении автоматизация конкретного теста выглядит несложной, но, начав работу, мы видим, что в текущей реализации или при определенных условиях она потребует значительных ресурсов. Давайте подумаем, есть ли у нас время и готов ли клиент заплатить за него?
Нужно ли автоматизировать простые тесты? Почему бы и нет! Может, следует перелопатить данные в JSON из 500 строк. Когда-то мне самой пришлось за день до релиза сравнивать JSON с данными, разбросанными по Excel-файлу. Не скажу, что проверка была слишком сложной, но при максимальной концентрации мне на нее понадобилось семь часов. Конечно, после того случая мы автоматизировали процесс!
А сложные, с математическими расчетами? Однозначно! Это обеспечит необходимую точность в подсчетах и исключит человеческий фактор.
В комментариях вы можете дополнить список!
Шаг 2. Давайте убедимся, что существующие тест-кейсы готовы к автоматизации
Что значит готовы к автоматизации? Начнем с оформления.
Во многих тест-менеджмент системах можно добавить атрибут для теста, который позволяет идентифицировать, нужно ли тест автоматизировать (причина также указывается) или он уже автоматизирован. По опыту скажу, что удобная штука, таким образом становится проще фильтровать и определять покрытие.
Вообще написание понятных и детальных тест-кейсов, как и ведение документации в целом — настоящее искусство. Хорошая практика — использовать ревью тест-кейсов, которые может выполнять как один из коллег, входящих в команду тестировщиков, так и ее лид или бизнес-аналитик. Взгляд со стороны полезен всегда, с его помощью можно не только убедиться, что мы ничего не пропустили, но и взглянуть на проект с точки зрения BA. Такой подход подтвердит, что мы покрыли все требования и пользовательские сценарии.
При дальнейшей проверке тест-кейсов рекомендую обратить внимание на следующие моменты:
- Если тест-кейсы пишут мануальщики. Зачастую тест-кейсы пишут они. Здорово, если мануальщики при этом имеют общее представление об автоматизации. Это позволит проанализировать ее возможность и целесообразность для конкретного сценария и осмысленно проставить отметку об автоматизации. Я неоднократно сталкивалась с ситуациями, когда мануальщики вовсе забывали проставлять этот атрибут и тест-кейсы терялись из фильтров. Или по привычке ставили его для всех тест-кейсов подряд. При необходимости всегда можно проконсультироваться с опытным коллегой-автоматизатором.
- Если тест-кейсы пишут автоматизаторы. В таком случае тест-кейсы могут быть написаны сугубо техническим языком, а пользовательский сценарий не будет понятен. Например, я сталкивалась с тестом, состоявшим из нескольких увесистых запросов: «выполни запрос 1», «выполни запрос 2». Опять же, если запрос вернул данные — это хорошо или плохо? Когда тест считается пройденным? Возможно, когда-то обсуждали, но через полгода этого уже никто не помнит. В целом это удобно, но разобраться, что именно проверяется, не вникнув в детали самого запроса, бывает сложно. Проверьте, понятны ли вам сценарии, или они все-таки требуют разъяснения.
- Детализация сценариев. Сценарии должны быть расписаны детально. Чтобы при дальнейшей автоматизации было очевидно, что нужно сделать, куда нажать и что проверить. Например, при выполнении сценария по работе с документом в конце остается шаг «сохраните документ». Этот шаг неоднозначен, поскольку это действие выполняется несколькими различными способами. Выбор одного из них может в корне изменить поведение автотеста, который в результате проверит не то, что было задумано. Мы ведь этого не хотим, правда? Старайтесь не заставлять другого человека додумывать, что вы имели в виду.
- Актуальность тестов. Тесты необходимо поддерживать в актуальном состоянии. Да, это сложно, но без этого не обойтись. Хорошая практика — сообщать автоматизаторам об изменениях до того, как их автотесты упадут. Например, мы знаем, что поменяется UI или где-то всплывет дополнительное окно. При ручном тестировании на такое можно даже не обратить внимания: мы же слышали о предстоящих изменениях и понимаем, что все хорошо. Остается нажать ОК и двинуться дальше. Но вот автотест точно ничего подобного не ожидает и начнет бить тревогу.
Шаг 3. Определитесь с данными, которые автотесты будут использовать
Зачастую автотесты сами генерируют данные для проверки и удаляют их после выполнения.
В этом есть свои плюсы и минусы: с одной стороны, мы стараемся никому не мешать — сами создали то, что нужно, проверили функционал на данных, в которых уверены, убрали за собой. К тому же так мы гарантируем необходимое покрытие. Но важно провести тестирование и на данных, с которыми работает пользователь или максимально приближенных. Если такие данные мы по какой-либо причине создать не можем, пользуемся тем, что уже есть, но после тестов данные не удаляем.
Почему так? «Реальные данные» имеют особенности: например, они могут быть импортированы в систему, сформированы другим путем, иметь более сложную логику — то, что будет сложно повторить для чистоты сценария.
Еще один нюанс — данные меняются часто. Если это ваш случай, давайте рассмотрим другой подход.
В какой-то момент в кейсах мы стали добавлять критерии к данным, которые нужно использовать. Они могут быть простыми: например, надо взять пользователя, который зарегистрировался в системе более года назад. Один из вариантов решения — запрос в базу с теми же критериями, для автотестов он даже удобнее. Такой подход подойдёт, если тест нужно выполнить на разных окружениях, где данные отличаются. Но есть и минус: если данные достаточно сложные, то есть критериев много (пользователь, зарегистрированный год назад, который не делал покупок товаров определенной категории в течение последних 3 месяцев), то будет сложно или даже невозможно их достать таким образом. Вероятно, проще будет подбирать данные вручную и подставлять хардкодом.
Чтобы не мешать друг другу при тестировании, используйте разные окружения или разделите данные для автотестов и ручного тестирования. Тогда при проверке определенного сценария вы не столкнетесь с проблемой случайного изменения данных.
Шаг 4. Оптимизируйте проверки
В процессе оптимизации автотестов не упускайте из виду важный момент — качество проверок. Мы стремимся сделать автотесты быстрее, это их очевидное преимущество по сравнению с ручным тестированием. Однако следите за тем, чтобы при этом было обеспечено и определенное покрытие.
Я на собственном опыте убедилась, что попытка ускорить проверку может неприятно отразиться на качестве. Например, отправлять запросы не через пользовательский интерфейс, а напрямую через API: тут есть где развернуться, и работа, конечно, пойдет быстрее. Но при таком подходе не проверяется UI, и это чревато последствиями. Юзеры использовать API не будут, а проблемы с интерфейсом заметят сразу — для пользовательских задач они станут однозначным блокером. Но если такая идея пришла вам в голову, возможно, пора разделить и скомбинировать проверки. Дальше спокойно продумывайте покрытие и оптимизируйте процесс в свое удовольствие.
Вместо заключения. Краткий список рекомендаций
Давайте подведем итоги и повторим, о чем следует помнить, запуская автоматизацию тестирования в проекте:
- убедитесь, что определили и обозначили все сценарии, которые целесообразно автоматизировать;
- комбинируйте проверки и пытайтесь обеспечить достаточное покрытие в плане функционала и данных;
- не выпускайте из виду пользовательские сценарии.
И главное помнить: цель любых тестов — найти проблемы, чтобы выпустить качественный продукт. Пусть автотесты будут «зелеными», а пользователи — довольными.
Все про українське ІТ в телеграмі — підписуйтеся на канал DOU
Автоматизация тестирования на проекте: что важно учесть
Специалисты по автоматизации тестирования (SDET, то есть Software Development Engineer in Test) помогают ускорить проведение тестов, а значит, быстрее выпускать свежие релизы IT-продукта. Как правило, это наиболее необходимо в масштабных приложениях с большим количеством бизнес-функций.
Рассмотрим, как бизнесу понять потребность в автотестах, с чего начать и как оценить эффективность результатов.
Когда на проекте нужна автоматизация
При работе с масштабными IT-решениями, например, системами дистанционного банковского обслуживания (ДБО), важно постоянно тестировать не только работу отдельных функциональностей, но и их взаимодействие. В условиях сжатых сроков, когда ведущие банки каждый месяц обновляют свои приложения, проверить все вручную невозможно – на это как минимум не хватит времени.
При создании IT-продуктов для бизнеса обычно сочетают два подхода:
- осуществляют проверки вручную, с помощью специалистов по обеспечению качества (QA);
- комбинируют ручное тестирование и автоматизацию отдельных тест-кейсов, смоук- и регрессионных тестов.
Как правило, мы привлекаем экспертов SDET для решения следующих задач:
- Автоматизация рутинных и частых проверок, снижение нагрузки на QA-специалистов.
- Контроль основных функций приложения и отслеживание изменений в продукте.
- Возможность проводить тестирование с большим количеством мобильных устройств, версий браузеров и операционных систем.
- Тестирование производительности приложения в условиях одновременной работы с большим количеством данных и пользователей.
Критерии автоматизации тестирования
Существует ряд признаков, указывающих на то, что пора задуматься о подключении SDET-специалиста на проект. Наличие их является своеобразными маркерами необходимости этого процесса.
Работы на проекте будут продолжаться минимум полгода
Если разработка проекта рассчитана на полгода и более, чаще всего за это время у команды накапливается некоторая база стабильного и неизменного функционала, тестирование которого можно автоматизировать.
Наличие продолжительных регрессионных тестов
Если повторные проверки (регрессионные тесты) занимают 3-4 дня и более, то автотесты помогут ускорить этот процесс за счет параллельного запуска, ночных прогонов и автоматической генерации отчетов.
Большое количество багов выявляется на поздних этапах тестирования
Внедрение автоматизации не решит такого рода проблемы на 100%, поскольку многое зависит от проекта и процессов на нем. Однако в данном случае у автотестов есть существенное преимущество – они могут запускаться в любое время, в том числе на этапе разработки. Это позволит выявлять возможные проблемы и ошибки раньше, чем задача будет передана в тестирование.
Тест-кейсы требуют создания большого количества тестовых данных или заполнения больших форм
В данном случае автоматизация тестирования решит проблему человеческого фактора. Автотест выполняет каждый раз одинаковую последовательность действий и проверяет один и тот же ожидаемый результат. Кроме того, заполнение и генерация данных в автоматическом режиме выполняется в разы быстрее, чем в ручном.
Тест-кейсы в основном проверяют функциональное поведение, а не интерфейс и юзабилити
Автоматизация тестирования может принести положительные результаты при проверке функциональности, тогда как визуальное тестирование эффективнее проводить вручную.
Если есть проблемы с производительностью и\или стабильностью работы систем
Проверить работу приложения или отдельных сервисов, используя тысячи одновременно работающих пользователей вручную – это очень трудно или даже невозможно. Автоматизированные сценарии, запущенные в тысячи потоков, создадут условия, необходимые для оценки работоспособности и производительности приложения.
На основании выполнения большинства из перечисленных условий, может быть принято решение о внедрении автоматизации тестирования на проекте.
C чего начинается автоматизация тестирования
После того, как решение о внедрении автоматизации принято, следует определить цель внедрения автоматизации тестирования, а также объект тестирования, ресурсы и процессы.
Наиболее частые цели автоматизации тестирования:
Сокращение time-to-market
Уменьшение времени от постановки задачи до выпуска приложения на production. SDET-специалисты помогают сократить время на тестирование устоявшейся функциональности приложения. Вместо того, чтобы проходить регрессионные кейсы руками, они автоматизируются. Прогон автотестов занимает в разы меньше времени, чем ручная работа. Кроме того, его можно запланировать на ночное время и запустить в несколько потоков, в зависимости от ваших аппаратных ресурсов.
Улучшение качества продукта и оптимизация затрат на тестирование
За счет автоматизации регрессионных кейсов отпадает необходимость в найме специалистов по ручному тестированию для прохождения постоянно увеличивающегося на развивающемся проекте регресса.
Проведение тестирования нагрузки и исследование производительности
Автоматизация позволяет эмулировать действия реального пользователя в системе в нужном количестве и нужного типа для проведения исследований нагрузки. Это позволяет моделировать различные ситуации повышенной нагрузки на систему и предугадать её поведение в таких ситуациях.
Какие ресурсы необходимы
Прежде чем приступать непосредственно к автоматизации, следует проанализировать условия, в которых предстоит работать, и уточнить, готовы ли необходимые ресурсы для ее старта:
Нужно выяснить, насколько вписываются ожидания клиента о времени запуска автоматизации в предполагаемые затраты на эти работы. Практика показывает, что затраты на SDET начинают окупаться в среднем спустя полгода после старта. Поэтому уточнение масштабов долгосрочности проекта является одним из ключевых факторов в принятии решении о необходимости автоматизации тестирования.
Следует выяснить, каков будет состав команды SDET. Возможны два варианта:
— у заказчика уже есть свои специалисты по автоматизации тестирования и им нужны просто дополнительные руки. Здесь имеет место вариант подключения к уже существующей команде “на усиление”.
— заказчик начинает автоматизацию “с нуля” без имеющихся собственных специалистов в этой области. В этом случае условия работы представляются совершенно иными, нежели в первом варианте.
Необходимо сразу определиться, выстроен ли на проекте процесс CI/CD, кто займется настройкой окружения для тестирования (SDET или DevOps), стенды для тестирования и доступ к ним у участников команды.
Инструменты для разработки и тестирования
До старта процесса разработки тестового фреймворка нужно определиться с используемыми технологиями и языками.
Следует произвести анализ проекта и в зависимости от его особенностей и требований к автоматизации выбрать наиболее оптимальный стек. При этом нужно учесть и навык работы специалистов, которые будут поддерживать и развивать проект автоматизации с этим стеком.
Как оценить эффективность автоматизации
При реализации проекта можно собрать метрики эффективности автоматизации, чтобы впоследствии проанализировать их и рассчитать процент эффективности.
Собираемые метрики можно разделить на две ключевые группы. Это:
- Количество часов, затраченных QA на прохождение тест-кейса.
- Количество часов, затраченных SDET на автоматизацию (актуализацию) тест-кейса.
Упрощенная формула расчета выглядит как Кол. ч. QA / Кол. ч. SDET * 100%
Пример: если на проекте впервые внедрена автоматизация тестирования, то ожидаемая экономия времени и других ресурсов за год в среднем составляет 140-150%. При этом эффективность автоматизации нарастает пропорционально времени ее использования, в частности, до 240% к концу второго года.
Если показатель экономии ресурсов со временем начинает снижаться, мы рекомендуем провести аудит тестирования и автоматизации тестирования для выявления возможных проблем, ошибок и узких мест.
Для расчета эффективности автоматизации важно иметь источник достоверной информации о временных затратах на автоматизацию тестирования. В частности, источником данных может быть система таск-трекинга на проекте, такая как Jira.
Из практики
Рассмотрим пример одного из наших проектов, в котором было порядка 700 тест-кейсов, каждый из них проходили от 70 до 100 раз в год. У нас была возможность автоматизировать 75% кейсов, а остальные требовали проверки вручную.
- 30 часов при ручной проверке всех кейсов.
- 8 часов после автоматизации (ночной прогон тестов без участия человека).
Помимо ночного прогона, нам требовалось около 8 часов на проверку тех кейсов, которые невозможно было покрыть автотестами, и 6 часов – на анализ результатов автотестов и проверку отказов в случае необходимости. Таким образом, автоматизация тестирования позволила снизить затраты времени специалистов с 30 до 14 часов. В среднем, этот подход позволяет экономить как минимум от 30 до 50% времени и уделить больше внимания развитию и улучшению продукта.
Выводы
Сочетая ручное тестирование и автотесты, мы контролируем качество ПО. SDET-специалисты, как правило, необходимы при реализации крупных IT-проектов, в которых задействованы несколько команд, со сложными алгоритмами и бизнес-логикой. За счет автоматизации мы снижаем риски ошибок, недопустимые в условиях жесткого расписания релизов.
В разработке автотестов используем наиболее востребованные языки программирования – Java, Python, Kotlin и др. В числе технологий и инструментов, с которыми мы работаем, Appium, TestNG, JUnit, RobotFramework, Pytest, Selenium, Selenide, Allure Report, TeamCity, Jenkins, JMeter.
Как QA организовать автоматизацию тестирования на проекте. Один практически примененный способ
Некоторое время назад я написала статью о своем опыте организации работы QA Инженера на проекте. Сейчас хочу продолжить эту тему, но уже в более узком ее направлении — автоматизации тестирования. Речь пойдет о том же самом проекте, он небольшой, но развивающийся под запросы постоянных клиентов. Быть может мой подход не очень подойдет командам, где работают много десятков сотрудников и каждый отвечает за свою часть (по-моему, в таких проектах работа каждого должна быть строго регламентирована, иначе такой махиной управлять просто невозможно, хотя и они найдут здравое зерно), но он точно будет интересен тем, кто, как и я, однажды пришел на новую работу, и встал на перепутье как самому организовывать свое место под новым солнцем.
Готовимся учиться
Итак, как же можно организовать автоматизацию тестирования на проекте? Если ваш ответ — взять замечательный Selenium и какой-нибудь фреймворк к нему и вперед, то с высоты 13-летнего опыта работы в тестировании я бы не стала так делать точно. Придется осваивать новые горизонты.
Чем же чреват подход «зациклиться на selenium»? А тем, что вы уже и сами не раз читали и слышали. Тем что, эти тесты UI-ные, они дорогие и долгие как в написании и прогоне, так и в поддержании работоспособности. Это знает каждый, но со всей болью этой истины сталкиваются лишь тогда, когда ее игнорируют. UI end-to-end автотесты должны быть обязательно, никто кроме них, не даст вам уверенности в том, что то, что увидит клиент после очередного деплоя не станет для него разочарованием. Но они не должны стать центром автоматизации вашего тестирования.
Возьмите за центр контроля за качеством вашего продукта Test Pyramid Principles. Те самые, о которых уже тоже много где сказано, но на практике не каждый QA понимает, как эту пирамиду сделать прикладной.
Ее рисуют вот так:
Каждый найдет вариант для своей архитектуры.
Внедряем Testing Pyramid Principles в работу QA
Во-первых, как бы лениво и непривычно это ни было, освойте белоящечное тестирование и станьте «частично девелопером».
Поднимите проект локально, так же как это делает каждый разработчик (наверняка, на проекте есть документация как это сделать, найдите). Вероятно, вы стопятьцот раз проклянете это дело, делая это в первый раз, у вас будет миллион вопросов и проблем, но когда вы это сделаете вы уже многое будете знать: каковы архитектурные идеи, какая база данных, что откуда куда пересылается, где нужные конфиги, а главное, где хранятся автотесты и как их запускать.
Во-вторых, разберитесь с автотестами, которые пишут сами разработчики.
Найдите их место в структуре проекта, какие виды тестирования и инструменты используются, как запускаются. Оцените покрытие проекта автотестами, научитесь ориентироваться в них. Есть множество инструментов для автоматической оценки покрытия, можете пользоваться, но я сейчас говорю не об этом. Я больше о развитии вашего чутья: берете кусок функционала и смотрите, как он покрыт автотестами: хорошо или плохо. Если хорошо, повод быть вам за эту часть спокойным, если плохо — вы нашли себе фронт работы на те дни, когда на повестке нет срочных задач. А пока при каждом прогоне регрешна имейте в виду, что это место в коде уязвимо.
В-третьих, наберитесь смелости, ревьюйте пулл реквесты разработчиков.
Каждый раз когда вы приступаете к разработке нового функционала, запишите себе все тест кейсы для него. Отметьте те из них, которые нужно обязательно автоматизировать, чтобы больше не возвращаться к ручному тестированию этого функционала. Ревьюйте пулл реквесты разработчиков и обоснованно требуйте реализацию тех автотестов, которые они пропустили. Мне много раз попадались очень крутые разработчики, которые писали классные тесты, но даже они уступали хорошему QA в понимании того, как точно, скорее всего, будет пользоваться продуктом конечный клиент. Поэтому даже для матерых спецов находится, что порекомендовать в написании автотестов.
В-четвертых, наберитесь еще большей смелости, и пишите автотесты прямо в коде продукта.
Да, также как это делают разработчики. Наравне с ними. Каждый раз когда вы сталкиваетесь с тест кейсом, который нужно автоматизировать, не бросайтесь сразу воплощать его обособленными инструментами, используемыми лишь внутри команды QA. А первым делом задайте себе вопрос, можно ли его автоматизировать посредством юнит/интеграционных автотестов в коде продукта? Если да, сделайте именно так. Если страшно, то это страшно только в первый раз, зато какой level-up ваших скиллов, ведь ваши пулл реквесты будут ревьюить опытные программисты. Да, сначала разнесут в пух и прах то, что вы сделали, но развитие всегда предполагает боль 🙂 Зато в итоге вы получите прекрасные дивиденды:
- такие тесты будут поддерживаться всей командой разработчиков
- они будут работать постоянно, непрерывно и быстро
- они будут интегрированы в CircleCi и запускаться при каждом деплое автоматически (если это реализовано на проекте)
- залатаются дыры в тестировании (вы напишите то, что не было написано до вас)
- вы сможете помочь разработчикам в написании тестов, если они не успевают
Это будут тесты, которые будут поддерживаться лишь командой QA. В них можно воплотить
- самые ходовые, критически важные сценарии клиентов
- то, что в интеграционных тестах в основном коде не удается полноценно воплотить, например, работу со сторонними сервисами
Что из этого получается
Сейчас я работаю именно по такому сценарию. В итоге на верхушке моей пирамиды тестирования всего 9 штук end-to-end тестов. И их поддержка — моя ответственность. А все остальные десятки и сотни тестов живут вместе с основным кодом продукта, начинают свою работу еще на локальном компе разработчика и поддерживаются всей командой инженеров.
Мои end-to-end тесты работают довольно долго, это связано с тем, что они загружают видео файлы на платформу, а потом конвертят их с разными параметрами, отправляют на обработку на сторонние сервисы, ждут ответа и так далее, совершенно без заглушек. Поэтому в автотестах много моментов ожидания окончания операции. Команде не понравилась перспектива иметь такие тесты в CircleCi, да и не нужно, на самом деле. Поэтому я реализовала их как джобы в Jenkins.
Когда все тестовые проверки в коде продукта пройдены, мы деплоим тестируемый бранч на тестовое окружение и прогоняем на нем end-to-end тесты посредством Jenkins. Еще несколько ручных функциональных тестов для пущей верности от QA и все, можно бранч мержить в мастер. Сегодня Jenkins джобы для автотестов на тестовом окружении гоняю не только я, разработчики постоянно запускают их, когда им нужно генерировать свежие тестовые данные и имитировать активности пользователей. Их немного, поэтому они стабильны и всегда работают. Удобно всем.
Отмечу еще одно приятное преимущество для QA Инженера в такой вот реализации пирамиды тестирования. Получается,, вы по полной программе становитесь частью команды инженеров. Вы, действительно, делаете неотъемлемую часть единой работы — пишете код вместе со всеми, просматриваете код разработчиков, общаетесь с ними, и они делают то же самое по отношению к вам. Вы видите работу друг друга, лучше collaboration, сильнее team building. Вы будете разбираетесь в проекте не только снаружи, но и изнутри, достойно уважения, не правда ли?
Заключительное напутствие
Моя статья не претендует на универсальную пилюлю, которую можно использовать всегда и везде. Все проекты очень разные, все команды очень разные — каждая должна строить свой самый лучший путь сама, часто это квинтэссенция разных подходов и инструментов. Даже знаменитый Скрам, сколько проектов я видела, каждый исповедует по-своему 🙂 Я вообще не верю в строгие инструкции, верю, что они нужны как ориентиры, а действовать нужно по ситуации.
Однако мир IT развивается, и в него приходят все новые и новые люди, поэтому уверена, что среди читающих этот материал обязательно найдется тот, кому мои маленькие инструкции помогут выбрать верный путь. Улыбнитесь мне в комментариях, если было полезно :), мне будет приятна обратная связь!
- qa automation
- автоматизация тестирования
- test automation
- test pyramid
- Тестирование IT-систем
- Тестирование веб-сервисов
- Управление разработкой
- Управление проектами
Как быстро начать автоматизацию тестирования на проекте
Technical QA Engineer в Sitecore, Преподаватель Компьютерной школы Hillel.
- 5:33 Про мотивацию начинающих QA Automation Engineer
- 10:44 С чего начать автоматизацию тестирования
- 12:30 Формирование конечной цели автоматизации
- 13:57 SMART критерии цели
- 18:38 Стратегия автоматизации тестирования
- 20:04 Быстрая стратегия автоматизации тестирования
- 23:50 Три вопроса, с которых следует начинать автоматизацию
- 24:14 Что будем автоматизировать
- 28:03 Коротко про Unit тесты
- 29:51 Зачем тестировать Unit тесты
- 32:44 Интеграционные тесты
- 39:32 System testing
- 42:14 Кто будет писать тесты
- 45:57 Как будем писать тесты
- 50:23 Выбор инструмента
- 59:15 Алгоритм выбора инструмента
- 1:02:16 Рекомендации по языкам
- 1:05:40 Какие тесты нужно автоматизировать в первую очередь
- 1:08:05 Стратегия Quick wins
- 1:12:10 Не пытайтесь в первый раз сделать все идеально
- 1:16:33 Live coding
Павел Сафонов, Technical QA Engineer в SiteCore, рассказывает, как подойти к автоматизации тестирования на проекте, с чего начать, как продумать тест план и начать формировать тест кейсы, как отбирать тесты для дальнейшей автоматизации, оценивать время работ и объяснит, как понять, нужна ли вам вообще автоматизация.
Рекомендуем курс по теме
QA Automation — Java advanced