какие тесты нужно автоматизировать

Какие тесты нужно автоматизировать

Что пишут в блогах

Продолжу хвастаться статусом книги.

I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:

Онлайн-тренинги

Что пишут в блогах (EN)

Introduction

Разделы портала

Про инструменты

Автор: Амир Гахрай (Amir Ghahrai)

Перевод: Ольга Алифанова

Как вы решаете, какие тесты автоматизировать, а какие оставить для ручного тестирования?

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

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

Вот некоторые идеи, помогающие выбрать хороших кандидатов на автоматизацию:

Тесты, которые должны быть автоматизированы:

В общем и целом, чем чаще прогоняется тест, тем лучше его автоматизировать.

Помните также, что тесты – не единственные кандидаты на автоматизацию. Задачи, например, настройка, создание тестовых данных для ручного тестирования – тоже прекрасные идеи для автоматизации.

Тесты, которые не нужно автоматизировать:

Источник

Лучшие практики автоматизации тестирования: решение, что и когда автоматизировать

Автоматизация тестирования обычно вводится в проект для решения таких проблем, как повторяющаяся ручная работа, работа с большими наборами данных или получение более быстрой обратной связи в пайплайне CI / CD. Из-за этого шума вокруг автоматизации тестирования вы можете подумать о том, чтобы автоматизировать «все». Возможно, вы уже выбрали фреймворк тестирования и команду, которая будет выполнять автоматизацию тестирования. Но серьезно ли вы задумывались о том, что вам следует автоматизировать или насколько это выполнимо для вас?

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

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

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

Автоматизируйте ваши смоук тесты

Смоук тесты очень важно выполнять для получения уверенности, что ваше приложение функционирует на базовом уровне, после каждого изменения или при создании нового билда. Смоук тесты могут быть интегрированы в пайплайн CI / CD, чтобы убедиться, что блокирующие ошибки обнаруживаются на ранней стадии. Смоук тесты гарантируют, что наиболее важные аспекты и основные компоненты приложения работают правильно. Они тестируют области, которые всегда должны работать, и могут помочь вам понять, достаточно ли стабильна сборка или приложение для продолжения дальнейшего тестирования. Автоматизация смоук тестов может:

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

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

Приводит к меньшему количеству ручного труда и экономит время. Путем интеграции ваших автотестов в пайплайн CI/CD ваши смоук тесты сворершают проверку до завершения сборки. Это означает, что сборка не передается QA, если автотесты не пройдут смоук.

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

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

Запускать тесты, которые быстро выявляют любые ошибки, возникающие в результате изменений в программном обеспечении. Эти изменения могут быть новыми функциями или исправлениями багов.

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

Экономить время, так как теперь вы можете сосредоточить свои усилия на ручном тестировании на большем количестве крайних кейсов.

Автоматизируйте обширные тесты

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

Автоматизируйте тесты, требующие нескольких конфигураций

Автоматизируйте ваши тесты производительности

Ваш следующий шаг

Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.

Источник

Автоматизация тестирования: что можно, а что не нужно

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

Главным элементом непрерывного тестирования является его автоматизация, что даёт множество преимуществ:

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

Кроме того, следует понимать — не всё нужно автоматизировать и не всё можно автоматизировать. Поэтому важно тщательно оценить, изучить и проанализировать свои требования, прежде чем решить, как лучше всего организовать автоматизацию тестирования. Когда следует автоматизировать тесты, а когда — нет?

Какие тесты можно автоматизировать

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

Модульное тестирование

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

Приоритетные функции

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

Регрессионные и интеграционные тесты

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

Нагрузочные тесты и тесты производительности

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

Повторяющиеся тестовые сценарии

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

Базовая функциональность (дымовые тесты)

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

Какие тесты не нужно автоматизировать

Всё больше и больше узнавая о преимуществах автоматизации тестирования и глубоко проникаясь ими, можно задаться закономерным вопросом — а почему бы не автоматизировать вообще все тесты? Ответ в виде «не нужно пытаться автоматизировать всё» идёт вразрез с DevOps-мышлением, в котором явная установка на автоматизацию всего и вся. Перед планированием автоматизации тестирования нужно учесть несколько факторов. Вот примеры тестов и сценариев, для которых не нужна автоматизация.

Пользовательский опыт (UX)

Эта область тестирования не может быть автоматизирована. Многие аспекты UX-проектирования требуют ручного, долгого и утомительного тестирования. Например, когда разработчики хотят понять, насколько легко пользователи могут зарегистрироваться на веб-сайте, или проверить, какие наборы полей дают лучшую видимость профилей пользователей. Подобные тесты должны быть проведены вручную.

Стадии ранней разработки

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

Функциональность, не имеющая большой важности

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

Тесты без понятных результатов

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

Тесты, которые невозможно полностью автоматизировать

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

Фреймворки автоматизированного тестирования

В каждой команде разработки и поставки ПО группа QA отвечает за разработку, внедрение и выполнение тестов. Для каждого типа тестирования должен быть определён тестовый сценарий, принципы, правила и инструменты для проведения. Фреймворк тестирования — это набор этих руководств, инструментов и практик, который помогает инженерам-тестировщикам эффективно выполнять тестовые сценарии.

Существуют разные фреймворки для разных целей тестирования. Вот некоторые из самых популярных типов фреймворков для автоматизированного тестирования:

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

Источник

Что дает автоматизация тестирования

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

Одни компании ошибочно считают, что автоматизация – пустая трата времени и средств, другие – что это крутой тренд и «таблетка» от всех болезней. Рассмотрим, где золотая середина и в чем смысл автоматизации.

Зачем тестировать

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

Например, одна из знаменитых “аварий” финансового мира произошла в Первом национальном банке Чикаго в конце 90-х: в одночасье счета клиентов безосновательно выросли на 900 миллионов долларов. Тогда старший вице-президент банка Джеймс Ланкастер признал, что дело в «программной ошибке в компьютере» – которую, к счастью, никто не успел использовать.

Дорогостоящие ошибки бывают и в других отраслях, казалось бы, не связанных напрямую с IT. Известный пример – аварии при запуске космической техники, в частности, в 2017 году Роскосмос утратил спутник стоимостью 2,6 млрд рублей.

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

При создании IT-продуктов для бизнеса обычно сочетают два подхода:

Что дает автоматизация

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

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

Когда автоматизация обязательна

Задачи автоматизации

Как правило, мы привлекаем экспертов SDET для решения следующих задач:

Результаты

Автоматизация помогает выстроить баланс:

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

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

Пример

Предположим, что на текущий момент в мобильном банке нужно проходить до 700 кейсов, каждый – от 70 до 100 раз в год. Ручной проверки требуют менее 25% кейсов, остальные 75% можно автоматизировать.

Затраты времени при ручной проверке:

Затраты времени при автоматизации:

Ночной прогон тестов занимает 8 часов, но без участия человека, поэтому не учитывается.

Прочие затраты времени:

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

В среднем, автоматизация экономит от 30 до 50% времени как минимум, позволяя выделить больше времени, например, на развитие и улучшение продукта.

Как происходит автоматизация тестирования

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

Процесс тестирования начинается с разработки стратегии – тест-плана, основы для составления отдельных тест-кейсов. Для автоматизации SDET инженеры выбирают ключевые, часто используемые сценарии работы пользователя с продуктом – такие сценарии дают около 80% бизнес-ценности.

После этого мы создаем основу для дальнейших автотестов, настраиваем стенды и workflow по работе с ними, CI для регулярного запуска тестов на различных ветках. Мы выбираем, какие подходы к подготовке тестовых данных мы будем использовать (API, доступ к базам данных, генерация синтетических данных, использование данных с прода). Инженеры SDET пишут тесты, которые покрывают ключевые сценарии работы с продуктом, анализируют полученные результаты и необходимость дальнейшей автоматизации.

Мы разрабатываем автоматизированные тесты, используя все наиболее востребованные языки программирования – Java, Python, Kotlin и др. Наши основные инструменты и технологии – Appium, TestNG | JUnit, RobotFramework | Pytest, Selenium | Senenide, Allure, TeamCity, Jenkins, JMeter.

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

Мы в своей практике выстраиваем процессы автоматизации тестирования уже на старте разработки, параллельно с ручным тестированием. Эта работа – не единоразовая, она ведется непрерывно, особенно на крупных проектах, в том числе банковских.

Подводя итоги

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

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

Спасибо за внимание! Надеемся, что статья была вам полезна!

Источник

Как правильно готовить автоматизацию или Что покрывать тестами в первую очередь

Привет, это Эрик Бурыгин, я техлид курса «Автоматизатор тестирования на Java» в Яндекс.Практикуме и лид в Яндексе. Каждый ручной тестировщик считает, что автоматизация — это круто и её непременно нужно втащить в проект. Что может быть лучше, чем полное покрытие автотестами продукта, когда тесты гоняются 24/7 и отлавливают баги? Вот прочитал я эти строки, и захотелось ещё раз всё заавтоматизировать!

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

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

Поймите, что автоматизировать в первую очередь

Для начала нужно чётко определиться с тем, что автоматизировать в первую очередь!

Давайте разберём все подводные камни такого пути на примере нашего проекта и пройдём путь ошибок и побед с самого начала.

«По просьбе выживших имена персонажей были изменены. Из уважения к погибшим всё показано так, как было на самом деле».

Итак, мы делаем приложение по продаже кастомных байков Custom Bike для платформ iOS и Android. Полный регресс приложения — это 2500+ кейсов на платформу и примерно несколько недель человеко-часов. Для написания тест-кейсов мы используем Testpalm от Яндекса. Релизимся часто. Но как бы мы не стремились ускорить процесс выкладки, регрессы оставались узким местом. Тестировщики утопали в них, теряя всякую мотивацию. Конечно, можно было нарастить команду, но это путь вникуда, так как новые фичи выкатываются каждый релиз и регресс становится всё необъятнее.

Вот мы и решили втащить в проект автоматизацию и, как вы наверное догадались, начали с регресса, а именно — с регресса Android-приложения. Благо культура автоматизации тестирования в команде была на высоком уровне — на тот момент мы очень преуспели в автоматизации веба и API. Но как всегда, без ложки дёгтя не обошлось — наша экспертиза в автоматизации мобилок была близка к нулю, а изучать новое было проблематично, ибо задач и так хватало. Как сейчас помню фразу: «Чтобы автоматизировать Android, нужно становиться Android-разработчиком».

Профит был, но мы всё равно не могли релизиться так часто, как хотели, а именно — выпускать релизы на каждой платформе раз в неделю. Начали думать и решили внедрить практику «смелых, до первой сломанной судьбы» — в каждом релизе пробегать не весь регресс, а проверять только места, где были изменения. Так у нас появились кастомные смоуки. В них входили дефолтные и критичные кейсы для приложения, а также кейсы на новые фичи и всё, что гипотетически могло быть затронуто. Этот подход хорош, но требует определённой экспертизы, потому что нужно обладать глубоким пониманием приложения и платформы и, конечно, уверенностью, что не выстрелит где-нибудь в неожиданном месте.

Кастомные смоуки дали хороший результат и сократили прохождение предрелизных кейсов до двух человеко-дней. Вы спросите: а как же 70% автоматизации? Дело в том, что смоук постоянно менялся, и не всегда тест-кейсы попадали в то, что уже было автоматизировано. К тому же автоматизация iOS находилась в зачаточном состоянии. При этом автотесты давали нехилую защиту от ошибок — перейдя на новый подход, некоторые из проверок мы стали делать очень редко.

Как понять, что автоматизировать

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

Testpalm позволяет без проблем выгрузить весь пул кейсов, что у нас есть.
Это можно сделать с помощью Python и библиотеки Requests. Пример:

Список кейсов получен, но нам нужна статистика, а пока мало что можно посчитать. Чтобы посчитать статистику, нужны маркеры. Testpalm отлично с этим справляется — там есть теги, поэтому мы начали при каждом сборе смоука добавлять тег-версию релиза: Android_4.11, Android_4.12, Android_4.13 и т. д. Это позволило нехитрым способом сосчитать, сколько раз каждый кейс был задействован в смоуках из выгруженного джейсона. Пример:

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

Пример получившегося списка:

ps://testpalm.ru/testcase/ Диплинки facebook 8
ps://testpalm.ru/testcase/ Реклама в листинге 8
ps://testpalm.ru/testcase/ Карточка мото 7
ps://testpalm.ru/testcase/ Геосаджест 7
ps://testpalm.ru/testcase/ Опция турбо 7
ps://testpalm.ru/testcase/ Опция продвижение 7
ps://testpalm.ru/testcase/ Опция поднятие 7
ps://testpalm.ru/testcase/ Реклама в карточке мото 6
ps://testpalm.ru/testcase/ Пожаловаться в карточке мото 6
ps://testpalm.ru/testcase/ Диплинки на выдачу 5
ps://testpalm.ru/testcase/ Смена региона 5

Теперь точно понятно! Но чтобы всё было по красоте, осталось обернуть полученные данные в табличку. Для хранения документации мы используем вики, и всё, что нужно было сделать — добавить вики-разметку в выводимый результат. Пример кода:

Так мы получили красивую легкочитаемую табличку.

Теперь понятно, с чего начинать автоматизацию, и актуальная статистика всегда будет под рукой. Круто! Но по мере автоматизации мы столкнулись с тем, что в статистику попадают кейсы, которые уже автоматизированы, или те, которые, наоборот, по какой-то причине нет смысла автоматизировать. Решение проблемы было простым — мы добавили ещё два тега:

Теперь табличка стала чище, и в ней остались только те кейсы, на которые нужно обратить внимание и завести задачи на автоматизацию. Для удобства добавили ещё один столбец — «Задача на автоматизацию». Пример кода:

Пример таблички в вёрстке:

Так как у нас помимо приложения Custom Bike есть и другие проекты, каждый из которых поддерживает iOS и Android, нужно было сделать скрипт формирования статистики более гибким. Мы ещё немного доработали код, и теперь при запуске скрипта можно передавать в него проект и платформу, получая статистику для нужного приложения. Пример запуска скрипта:

Чтобы в табличке был только топ самых используемых кейсов, мы добавили чувствительность, которую также можно передавать в скрипт. Пример запуска скрипта:

Вот теперь всё стало по красоте!

Заключение

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

В смоуке, как правило, все кейсы разные, и с помощью нашего подхода мы перекрываем большую часть уникальных сценариев, что позволяет наработать хорошую кодовую базу. С ней можно двигаться дальше и писать тесты по образу и подобию уже имеющихся. Ещё хочется отметить, что такой подход подойдёт как устоявшимся проектам, так и стартапам. И не забываем про хорошую и понятную отчётность — будет что показать руководителю и менеджерам. Кроме того, отчётность позволит легко ориентироваться в тестовом покрытии — с этой задачей отлично справится Allure.

Надеюсь, статья показалась вам интересной. Если у вас остались вопросы или есть собственные идеи по поводу автоматизации — пишите в комментарии, обсудим.

Источник