автотестирование с чего начать

Автоматизация тестирования «с нуля» (нетехническая сторона вопроса)

Есть множество статей про технологии и те или иные подходы к автоматизации. Но почему-то нет статей про «обратную сторону» автоматизации. Как вообще всё зарождается на проекте? И как это «всё» организовать?

Итак, здравствуйте! Меня зовут Ярослав, я являюсь лидером автоматизации тестирования в Центре развития финансовых технологий Россельхозбанка. В этой статье поделюсь своим опытом организации автоматизации на примере большого проекта РСХБ из 8 команд.

Общая информация по проекту

Большой проект с командами, разрабатывающими общий продукт.

В командах есть QA Manual (Ручной тестировщик).

Направления тестирования — Frontend, Backend.

Изучаем проект

Понимаем цель разработки продукта и кто потребитель

Ответы на эти вопросы помогают понять, на что делать упор в автоматизации. Например, если работаем с юридическими лицами, то делаем упор на тестирование «исполнения законодательства» и переводы по платежам и тд. Если это физические лица, то на основные выполняемые операции: переводы с карты на карту, оплату услуг и тп. Так же важно, чтобы направление автоматизации «смотрело» в целом на продукт, а не на отдельные в нем команды.

Знакомимся с участниками разработки продукта

Выделю ключевых людей:

Владельцы продуктов (Product Owners), они заказчики автоматизации в команде.

QA каждой команды. Они — это клиенты инструмента автоматизации, их уровень счастья — это показатель успеха.

Лидер ручного тестирования. Помогает в организации процесса и во взаимодействии с ручным тестированием.

Лидер разработки Frontend. Он влияет на стабильность и качество автотестов.

Специалист по закупке. Решит вопросы выделения техники, в основном с серверным железом.

Изучаем каждую команду

Собираем информацию о том, какую часть проекта разрабатывает команда.

Разбираемся в направлении — Frontend, Backend или всё сразу.

Разбираемся с тем, как QA тестируют свою часть продукта.

Выясняем, на каком уровне QA manual знаком с автоматизацией.

Находим боли в тестировании и что приоритетно закрыть автоматизацией.

Формируем требования к автоматизации и заказываем ресурсы

Что мы собрали?

У нас есть 8 команд.

Есть 11 QA инженеров.

Есть направления тестирования Frontend, Backend + будем «ходить» в Базу данных.

90% QA manual никогда не занимались автоматизацией.

Исходя из данных, формируем требования к автоматизации

У нас нет задачи делать какие-то инновационные решения, поэтому придерживаемся классики:

В качестве языка программирования выбираем Java — так будет проще найти специалистов.

Нужно тестировать Frontend. Берем Selenium.

Нужно тестировать Backend. Взаимодействуем с ним через REST. Берем REST-assured.

Нужно «ходить» в базу данных. Возьмем стандартные библиотеки из Java.

Нужно либо обучить QA manual разработке автотестов, либо нанять армию из N автоматизаторов. Мы думаем о расходах проекта на тестирование, поэтому убиваем 2-х зайцев сразу. Берем Cucumber.

Нам нужна отчетность с красивыми графиками. Берем Allure.

Получился следующий стек технологий: Java, Selenium, REST-assured, Cucumber.

Оцениваем силы автоматизаторов

Поскольку их нет, берем 1 автоматизатора на 5 команд (больше 5-и не потянет).

Автотесты нужно где-то запускать

Что нам понадобится?

Машина для Jenkins. 1 штука. Через него реализуем удаленный запуск.

Машина под Slave Jenkins. Как agent для Jenkins.

Машина под Selenoid. Для параллельного запуска тестов.

Делаем демо нашего инструмента

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

Берем команду в качестве первой «жертвы» автоматизации. Ребята разрабатывают Frontend. Нам нужна наглядность.

Делаем 5-10 автотестов. Записываем на видео.

Обязательно после прогона показываем Allure. Красивые графики любят все.

Рисуем «инфраструктуру автотестов». Главное, чтобы было просто и понятно.

Обозначаем главную цель автоматизации.

Демонстрируем эффект от автоматизации.

Делаем сравнительные тесты. Ручное прохождение и автоматизированное.

Показываем, как создаются сценарии.

Показываем планы автоматизации (когда появятся тот или иной функционал).

Показываем, как будет происходить внедрение автоматизации в команды.

Подготавливаем UI к автоматизации

Для обеспечения надежности, стабильности и качества автотестов, необходимо раскидать якоря на UI. Централизованно через лидера Frontend и дополнительно через владельцев продукта проставляем атрибут для UI-элементов “data-test-id“ или с любым другим названием. Смысл в том, чтобы со стороны UI проставить этот атрибут во всех элементах типа «Таблица, поле для ввода, кнопка» и тд. Если коротко, то на всех элементах, с которыми взаимодействуем, это даст +300% к надежности автотестов. Переезд элемента в другое место или изменение его содержимого никак не повлияют на проверку автотестом. Делаем этот момент обязательным для всех новых фич.

Разрабатываем автотесты

Делим команды между автотестерами.

Разрабатываем каркас проекта для автоматизации. Все по шаблону.

Подготавливаем набор Cucumber шагов для работы с Frontend, основным направлением в тестировании. Выносим шаги в отдельный проект и делаем из него подключаемый артефакт.

Настраиваем Selenoid и Jenkins.

Начинаем подключать команды к автоматизации. При подключении команды все сводится к тому, чтобы создать репозиторий, загрузить каркас, создать Job в Jenkins по шаблону, обучить QA работе с Cucumber, работе с Git и средой разработки.

После обучения QA manual самостоятельно пишут автотесты. Один раз за спринт автоматизатор приходит в команду и принимает написанные автотесты, делает правки и вливает в основную ветку. На этом этапе ребята качают уровень написания правильных сценариев, а мы получаем качественные проверенные сценарии.

После встречи со всеми командами у автоматизатора в спринте остается еще 5-6 свободных дней. Это время тратим на разработку Cucumber шагов.

В конце спринта на продуктовом демо показываем результаты по командам и делаем анонсы новых фич в инструменте.

Результаты

6 спринтов (60 дней), 8 команд, 2 автотестера и 11 ручных тестировщиков — имеем 50% покрытия регресса проекта автотестами. Это с учетом подключения команд (подключались постепенно) и разработки шагов.

4 вещи, о которых нужно помнить при разработке с таким подходом

Ручной тестировщик — это клиент

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

Ориентация на выгоду для проекта

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

Как мы их экономим?

Автотестами: находим дефекты запуская их каждый день.

На каждом этапе тестирования сокращаем время регресса.

Все это приводит к более быстрому выпуску продукта в промышленную эксплуатацию.

Не работает? Меняй!

Не нужно бояться ошибок. Их будет очень много в разработке, в общении с командами, во взаимодействии с QA инженерами, в демо. Главное увидеть, что «что-то» не работает и менять подход до тех пор, пока все не будут в восторге. Всё делаем для людей. Не для себя.

Кайфуй

Наверное, самое главное в любой работе — это получать удовольствие. До сих пор с умилением смотрю на автотесты. Я тоже был QA manual инженером и прекрасно понимаю, насколько нудно тестировать регресс раз за разом. Автотесты — это бальзам:)

Источник

Путь тестировщика: с чего начинать изучение автоматизации

Шесть лет назад Роман Печерский из Ижевска прошёл курсы для функциональных тестировщиков и начал работать QA-инженером. Спустя несколько месяцев он впервые столкнулся с автоматизацией тестирования и понял, что хочет развиваться в эту сторону.

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

Как я познакомился с автоматизацией

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

Кто-то из коллег по проекту рассказал мне про Selenium IDE – инструмент для автоматизации действий Firefox-браузера. Помню, как написал свой первый автотест с помощью метода Record and Play: включил запись, начал нажимать кнопки, вводить текст в поисковую строку и кликать по ссылкам. Получился набор сохранённых действий, который можно было запускать и сразу видеть результат.

Знакомства с Selenium IDE и этих лекций мне вполне хватило, чтобы решить ту проектную задачу и начать делать первые шаги в сторону в автоматизации.

Как я учился автоматизации

Вскоре я начал самостоятельно изучать Java – один из самых популярных языков для автоматизации тестирования – и пробовать писать несложные автотесты в Eclipse, например, для тестирования login-формы приложений.

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

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

Вот что помогало мне преодолевать трудности:

• Понимание, зачем это нужно

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

• Поддержка коллег

Всегда приятно, когда тебя кто-то подбадривает – особенно люди, которые уже прошли тот же путь.

• Чувство соперничества

Ощущение, что я могу стать самым отстающим студентом в группе, также подстёгивало меня двигаться вперёд.

Когда курсы закончились, я начал работать на проекте, чередуя обязанности функционального тестировщика и автоматизатора. Через несколько месяцев присоединился к новому проекту – уже в роли тимлида. QA-команда состояла всего из двух человек – меня и функционального тестировщика, которому я объяснял основы автоматизации.

Как я начал обучать автоматизации

Мой коллега по проекту – первый человек, которого я начал обучать автоматизации. Сначала моих знаний не всегда хватало, чтобы отвечать на его вопросы и помогать решать проектные задачи. Но когда я не мог ему что-то объяснить, то понимал, что сам недостаточно развиваюсь в теме и подтягивал знания. Обычно я искал ответы на Stack Overflow или обращался за помощью к разработчикам.

Постепенно моя команда выросла до 10 автоматизаторов. К тому времени я полностью отошёл от ручного тестирования и занимался комплексным системным автотестированием веб-приложений. Затем начал помогать команде с созданием архитектурных решений для тестов и стал проектным координатором.

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

Недавно я сам прошёл небольшой курс – по JavaScript – и подключился к новому проекту. Раньше я никогда не сталкивался с JS. Мне потребовалось около месяца, чтобы начать более-менее уверенно чувствовать себя в работе с новым языком.

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

• Начните с практики – создайте собственный автотест

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

Я считаю, что начинать нужно с простых вещей. Создайте несложный автотест сами. Чтобы было интереснее, попробуйте решить какую-нибудь жизненную задачу. Например, напишите скрипт, автоматизирующий передачу показаний счётчиков воды на сайт водоканала. Сегодня это можно сделать с помощью Katalon Studio, который пришёл на смену Selenium IDE. Такие задания подогревают интерес к изучению автоматизации. Затем можно будет переходить к изучению теории и специфики автоматизации, а также начать осваивать язык программирования в связке с Selenium WebDriver.

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

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

• Начните учиться самостоятельно или пройдите курсы

Курсы – хороший вариант для тех, кто вообще не имеет представления о том, с чего начать, или хочет систематизировать свои знания. Онлайн-курсы можно найти на Otus, Stepik, GeekBrains, Lynda, JavaRush. Если говорить об офлайн-обучении, его могут организовывать разные IT-компании вашего города: учебный центр EPAM, например, работает в шести российских городах.

Обычно программа любого курса по автоматизации разделена на три модуля:

1. Введение в теорию автоматизации;
2. Изучение основ языка программирования (например, Java);
3. Написание собственных автотестов.

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

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

• Понимание основных понятий тестирования: тест-кейсы, дефекты и т.д.;
• Понимание, что можно автоматизировать, а что нет;
• Знание основ языка программирования (Java, JavaScript, Python, C#);
• Умение работать с Selenium WebDriver;
• Умение писать локаторы для элементов;
• Знание одного-двух юнит-фреймворков.

• Как можно больше интересуйтесь

Новичков в автоматизации чаще всего отпугивают ошибки в коде. Они запускают код, видят, как что-то идёт не так, и впадают в ступор. Что делать в такой ситуации? Попробовать найти решение в интернете, например, на том же Stack Overflow. Ещё один вариант – попросить помощи у более опытных коллег. Они тоже когда-то были на вашем месте и делали такие же ошибки. Обсуждая какую-либо задачу с опытными автоматизаторами, вы расширяете свой профессиональный кругозор.

• Не стойте на месте

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

За пять с половиной лет, что я работаю с автоматизацией, я ни разу не пожалел, что выбрал это направление. Мне нравилось выполнять и задачи ручного тестирования, но я понимал, что рано или поздно упрусь в потолок. Потолок для мануальщика наступает, когда он тестирует разные виды приложений – веб, десктопные, мобильные – настолько профессионально, что работа перестает подбрасывать новые вызовы и превращается в рутину. Чтобы не стоять на месте и развиваться дальше, необходимо получить какой-то новый навык. Можно заняться автоматизацией функционального или нагрузочного тестирования, можно переключиться на тестирование безопасности или, например, разобраться в базах данных. Ещё можно посмотреть в сторону DevOps, бизнес-анализа или проектного менеджмента.

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

Источник

Как стать автоматизатором тестирования?

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

Эта статья полезна не только для мануальных тестировщиков, желающих автоматизировать свои рутинные проверки, но и для бизнеса и HR-ов, которые ввиду отсутствия каких-либо общепринятых критериев, как правило, понятия не имеют кто есть QA Automation Engineer и в большинстве случаев принимают решение на основании «хороший человек».

Бывает ещё хуже – руководитель/PM/etc… приходят к своим мануальным тестировщикам и говорят: «слушай, а может мы автоматизируем наше тестирование – это сэкономит нам кучу времени и денег. Скажи, какие книги тебе нужны и какие курсы».

Итак, мы узнаём, что такое примитивы, классы, объекты, полиморфизм, инкапсуляция, интерфейсы, абстрактные классы, статические поля, циклы, массивы, листы, мапы, потоки и так далее… Это изучение будет продолжаться в целом всё время, даже когда вы уже автоматизируете тестирование. Но на базовом уровне – Junior Java Developer – вы должны (если выбрали Java) быть знакомы с языком и иметь соответствующие навыки, потому как первичная локализация возникшей проблемы лежит на ваших плечах. Забудьте про «а вот у меня сценарий, ошибка наигрывается непонятно как и непонятно почему» — ваша задача, чтобы разработчик знал, что тут вот рядом человек может найти баги даже не запуская приложение. Не поверите, как вдруг качество продукта возрастает, когда есть человек, который не просто слышит запах плохо пахнущего кода, но и может предложить решения по улучшению.

Мы плавно перешли к

2. Использование шаблонов проектирования для разработки тестового фреймворка.
ДА-ДА. Вы открыли, например, Selenium, — всякие примеры, скопировали бездумно, написали на получившемся «фрэймворке» 1000 тестов. Приходит заказчик к бизнесу, говорит «мне тут нужно кое-что переделать», бизнес приходит к разработчику — «нам тут нужно немного подстроиться под рынок», разработчик всё прекрасным образом запиливает, — 90% тестов падают. Приходят к автоматизатору «мы тут немного поменяли, надо привести тесты в порядок», а автоматизатор в ответ «тут работы на месяц»… Упс…
Архитектура фрэймворка, который вы пишите, должна не просто быть гибкой, а должна постоянно стремиться минимизировать время рефакторинга имеющихся тестов и написания новых. В идеале, если разработчик и автоматизатор одновременно садятся исправлять что-либо, то автоматизатор должен сделать всё быстрее и предоставить разработчику некую форму TDD.

В создании такой чудо-архитектуры нам помогают паттерны проектирования и их грамотное использование… Builder, Facade, Factory, Null Object, Singleton, Adapter и многие другие паттерны активно помогают в решении подобных задач. Грамотная архитектура тестового фреймворка – это счастье для вас, для разработчиков, для бизнеса…и в конечном счёте для пользователя. Помните, что экспоненциальный рост ресурсов поддержки тестов при линейном росте/изменении функционала свидетельствует о том, что вам пора дорабатывать архитектуру движка. С наиболее полным списком паттернов с примерами на Java можете ознакомиться здесь. Отдельно отмечу Page Object Pattern, но лучше, сначала познакомиться с классическими.

3. Использование библиотек
То, что плавно вливается в любые задачи, — внешние API, библиотеки, драйверы и прочие прелести. Selenium — тестируем Web, Robotium/Espresso — тестируем Android, Fest/Jemmy — тестируем Java Swing, JemmyFX — тестируем JavaFX, замечательные Apache HttpComponents — делаем запросы и тестируем множество API, GSON — помогает приводить json к объектной модели и обратно и так до бесконечности… Библиотек прекрасных много написано почти под любую задачу — про некоторые из них можно почитать здесь. Не стоит бояться того, что их много — вы уже достаточно знаете, чтобы выбрать то, что вам подходит/нравится/вписывается в архитектуру. Например, под тестирование Java Swing приложений я использую JUnit, Fest, Mockito и широкие возможности java.lang.reflect — этого набора мне более чем хватает.

Будьте готовы к частому посещению stackoverflow и подобных ресурсов на ранних этапах. Будьте готовы к тому, что иногда надо будет заглянуть в исходники. И самое главное — не бойтесь не разобраться.

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

P.S.
К бизнесу, руководителям, специалистам по подбору персонала:

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

Источник

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

Привет, это Эрик Бурыгин, я техлид курса «Автоматизатор тестирования на 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.

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

Источник