Автоматизация тестирования: подготовка стратегии и подводные камни внедрения
Я работаю в IT больше двенадцати лет, четыре из которых — лидом команды тестировщиков. Как и все, мы пытаемся внедрять автотесты, чтобы ускорить процесс, увеличить тестовое покрытие и вообще облегчить себе жизнь и работу.
Думаю, основанный на опыте нашей команды материал будет полезен тем, кто только начинает выстраивать процесс автоматизации или недоволен тем, что из этого пока получается. Скажу сразу, что не буду вдаваться в технические детали или перечислять конкретные инструменты: это требует индивидуального подхода в зависимости от приложения и конкретной команды. Я же сосредоточусь на общем подходе и стратегии. Поделюсь основными идеями и подводными камнями, с которыми мы уже успели столкнуться, и попробую помочь вам избежать их в будущем. Некоторые вещи кажутся очевидными тем, у кого опыт автоматизации уже есть, но иногда стоит вернуться к истокам и вспомнить простые правила, которые часто забываются со временем. Итак, поехали.
С чего начать формировать стратегию
Думаю, всем доводилось получать сообщения от пользователей о багах, не обнаруженных автотестами. На самом деле, невнимательны бывают и пользователи, и мы с вами не всегда идеально понимаем нюансы бизнеса, для которого разрабатываем продукт, или не можем покрыть все сценарии. Например, был такой случай на одном из тестовых окружений. Тест переходил по ссылке и проверял, чтобы новая страница открывалась, причем только сам факт этого. Однако открытие страницы с надписью «У вас нет прав для просмотра» тоже проходило как успешный сценарий, хотя таковым не являлось. В итоге проблема есть, но тест успешен. В любом случае процесс можно улучшить, и автотесты — мощный инструмент для этого.
Автоматизацию тестирования лучше всего начинать с применения ко всей работе стандартной пирамиды, в основе которой лежат юниты и интеграционные тесты от разработчиков.
Дальше — в зависимости от частоты выполнения того или иного типа тестирования, необходимости и рисков. Поэтому следующими автоматизируют smoke-тесты, затем переходят к функциональным или регрессионным. Потом можно внедрять автоматизированное тестирование на уровне Continuous Delivery, но всему свое время.
Шаг 1. Выбираем функционал для автоматизации
Если уже есть написанные заранее тест-кейсы — это хорошо, на их основе мы и будем строить анализ. Если тест-кейсов нет, что ж, пора их написать.
Обратим внимание на следующие пункты.
Можно ли в принципе автоматизировать те или иные сценарии и целесообразно ли это? Например, запись в базе появится через полчаса-час после добавления, есть ли смысл автотесту ждать этого? В принципе подождать можно, но ускорим ли мы в этом случае процесс тестирования в целом? А ведь обычно в этом и заключена едва ли не основная цель автоматизации. Получается, заменять ручное тестирование в таком процессе нужно, только если мы хотим полностью избавить наших Manual QA от необходимости смотреть в эту сторону.
А если сценарий простой, а проверка разовая, надо ли тратить время на ее автоматизацию? Теоретически да, особенно если клиент требует «автоматизировать абсолютно всё!». Но учтите, что это неизбежно влечет дополнительные расходы. Готовы ли вы к ним в текущем проекте? Может, стоит внимательно посмотреть на нечто более важное?
Наконец, если каждый раз данные для теста нужно тщательно подбирать вручную, есть ли смысл в автоматизации? Для сложных финансовых систем не всегда есть возможность составить универсальный запрос для получения информации. Целесообразно ли в вашем случае вручную формировать данные при каждом запуске автотеста?
Существуют и тесты, где человек быстрее и с большей вероятностью заметит ошибку. Следует ли выстраивать проверки на необходимые ожидания с помощью скриптов?
Окупятся ли ресурсы, потраченные на автоматизацию? В первом приближении автоматизация конкретного теста выглядит несложной, но, начав работу, мы видим, что в текущей реализации или при определенных условиях она потребует значительных ресурсов. Давайте подумаем, есть ли у нас время и готов ли клиент заплатить за него?
Нужно ли автоматизировать простые тесты? Почему бы и нет! Может, следует перелопатить данные в JSON из 500 строк. Когда-то мне самой пришлось за день до релиза сравнивать JSON с данными, разбросанными по Excel-файлу. Не скажу, что проверка была слишком сложной, но при максимальной концентрации мне на нее понадобилось семь часов. Конечно, после того случая мы автоматизировали процесс!
А сложные, с математическими расчетами? Однозначно! Это обеспечит необходимую точность в подсчетах и исключит человеческий фактор.
В комментариях вы можете дополнить список!
Шаг 2. Давайте убедимся, что существующие тест-кейсы готовы к автоматизации
Что значит готовы к автоматизации? Начнем с оформления.
Во многих тест-менеджмент системах можно добавить атрибут для теста, который позволяет идентифицировать, нужно ли тест автоматизировать (причина также указывается) или он уже автоматизирован. По опыту скажу, что удобная штука, таким образом становится проще фильтровать и определять покрытие.
Вообще написание понятных и детальных тест-кейсов, как и ведение документации в целом — настоящее искусство. Хорошая практика — использовать ревью тест-кейсов, которые может выполнять как один из коллег, входящих в команду тестировщиков, так и ее лид или бизнес-аналитик. Взгляд со стороны полезен всегда, с его помощью можно не только убедиться, что мы ничего не пропустили, но и взглянуть на проект с точки зрения BA. Такой подход подтвердит, что мы покрыли все требования и пользовательские сценарии.
При дальнейшей проверке тест-кейсов рекомендую обратить внимание на следующие моменты:
- Если тест-кейсы пишут мануальщики. Зачастую тест-кейсы пишут они. Здорово, если мануальщики при этом имеют общее представление об автоматизации. Это позволит проанализировать ее возможность и целесообразность для конкретного сценария и осмысленно проставить отметку об автоматизации. Я неоднократно сталкивалась с ситуациями, когда мануальщики вовсе забывали проставлять этот атрибут и тест-кейсы терялись из фильтров. Или по привычке ставили его для всех тест-кейсов подряд. При необходимости всегда можно проконсультироваться с опытным коллегой-автоматизатором.
- Если тест-кейсы пишут автоматизаторы. В таком случае тест-кейсы могут быть написаны сугубо техническим языком, а пользовательский сценарий не будет понятен. Например, я сталкивалась с тестом, состоявшим из нескольких увесистых запросов: «выполни запрос 1», «выполни запрос 2». Опять же, если запрос вернул данные — это хорошо или плохо? Когда тест считается пройденным? Возможно, когда-то обсуждали, но через полгода этого уже никто не помнит. В целом это удобно, но разобраться, что именно проверяется, не вникнув в детали самого запроса, бывает сложно. Проверьте, понятны ли вам сценарии, или они все-таки требуют разъяснения.
- Детализация сценариев. Сценарии должны быть расписаны детально. Чтобы при дальнейшей автоматизации было очевидно, что нужно сделать, куда нажать и что проверить. Например, при выполнении сценария по работе с документом в конце остается шаг «сохраните документ». Этот шаг неоднозначен, поскольку это действие выполняется несколькими различными способами. Выбор одного из них может в корне изменить поведение автотеста, который в результате проверит не то, что было задумано. Мы ведь этого не хотим, правда? Старайтесь не заставлять другого человека додумывать, что вы имели в виду.
- Актуальность тестов. Тесты необходимо поддерживать в актуальном состоянии. Да, это сложно, но без этого не обойтись. Хорошая практика — сообщать автоматизаторам об изменениях до того, как их автотесты упадут. Например, мы знаем, что поменяется UI или где-то всплывет дополнительное окно. При ручном тестировании на такое можно даже не обратить внимания: мы же слышали о предстоящих изменениях и понимаем, что все хорошо. Остается нажать ОК и двинуться дальше. Но вот автотест точно ничего подобного не ожидает и начнет бить тревогу.
Шаг 3. Определитесь с данными, которые автотесты будут использовать
Зачастую автотесты сами генерируют данные для проверки и удаляют их после выполнения.
В этом есть свои плюсы и минусы: с одной стороны, мы стараемся никому не мешать — сами создали то, что нужно, проверили функционал на данных, в которых уверены, убрали за собой. К тому же так мы гарантируем необходимое покрытие. Но важно провести тестирование и на данных, с которыми работает пользователь или максимально приближенных. Если такие данные мы по какой-либо причине создать не можем, пользуемся тем, что уже есть, но после тестов данные не удаляем.
Почему так? «Реальные данные» имеют особенности: например, они могут быть импортированы в систему, сформированы другим путем, иметь более сложную логику — то, что будет сложно повторить для чистоты сценария.
Еще один нюанс — данные меняются часто. Если это ваш случай, давайте рассмотрим другой подход.
В какой-то момент в кейсах мы стали добавлять критерии к данным, которые нужно использовать. Они могут быть простыми: например, надо взять пользователя, который зарегистрировался в системе более года назад. Один из вариантов решения — запрос в базу с теми же критериями, для автотестов он даже удобнее. Такой подход подойдёт, если тест нужно выполнить на разных окружениях, где данные отличаются. Но есть и минус: если данные достаточно сложные, то есть критериев много (пользователь, зарегистрированный год назад, который не делал покупок товаров определенной категории в течение последних 3 месяцев), то будет сложно или даже невозможно их достать таким образом. Вероятно, проще будет подбирать данные вручную и подставлять хардкодом.
Чтобы не мешать друг другу при тестировании, используйте разные окружения или разделите данные для автотестов и ручного тестирования. Тогда при проверке определенного сценария вы не столкнетесь с проблемой случайного изменения данных.
Шаг 4. Оптимизируйте проверки
В процессе оптимизации автотестов не упускайте из виду важный момент — качество проверок. Мы стремимся сделать автотесты быстрее, это их очевидное преимущество по сравнению с ручным тестированием. Однако следите за тем, чтобы при этом было обеспечено и определенное покрытие.
Я на собственном опыте убедилась, что попытка ускорить проверку может неприятно отразиться на качестве. Например, отправлять запросы не через пользовательский интерфейс, а напрямую через API: тут есть где развернуться, и работа, конечно, пойдет быстрее. Но при таком подходе не проверяется UI, и это чревато последствиями. Юзеры использовать API не будут, а проблемы с интерфейсом заметят сразу — для пользовательских задач они станут однозначным блокером. Но если такая идея пришла вам в голову, возможно, пора разделить и скомбинировать проверки. Дальше спокойно продумывайте покрытие и оптимизируйте процесс в свое удовольствие.
Вместо заключения. Краткий список рекомендаций
Давайте подведем итоги и повторим, о чем следует помнить, запуская автоматизацию тестирования в проекте:
- убедитесь, что определили и обозначили все сценарии, которые целесообразно автоматизировать;
- комбинируйте проверки и пытайтесь обеспечить достаточное покрытие в плане функционала и данных;
- не выпускайте из виду пользовательские сценарии.
И главное помнить: цель любых тестов — найти проблемы, чтобы выпустить качественный продукт. Пусть автотесты будут «зелеными», а пользователи — довольными.
