Что делать, если вы маленькая команда из 2-3 человек, которая делает интересное решение в корпоративном секторе, но у вас проблемы со сроками, качеством продукта, а на ручное тестирование совсем нет времени?
Именно с такой проблемой столкнулись мои старые знакомые, которым я помог сэкономить на том, чтобы не нанимать отряд ручных тестировщиков, при этом повысив качество продукта и удовлетворенность клиентов.
В статье я постарался проанализировать проблему, описать решение, которое они пробовали, и рассказать о решении, которое им помогло.
Анализ проблемы команды разработки
Когда ко мне обратился один из членов этой команды, в первую очередь потребовалось выяснить "в чем вообще заключается проблема". Неужели они не закладывают время на написание и исполнение автотестов при планировании задач? Как оказалось - закладывают даже с избытком, и в целом эти тесты выглядят довольно адекватно.
Проблема была в том, что если на программном уровне все было "в порядке", то на уровне пользовательского интерфейса постоянно возникали несостыковки: то кнопочка отвязывается от события, то поля местами путаются, то целый блок появляется на несвойственной ему странице.
Возможно, это навыки разработки фронта так страдают у ребят, но это нельзя вылечить в один момент. Нанять еще одного, более опытного разработчика, чтобы "учил их уму разуму" - бюджет не позволяет, а уволить кого-то для высвобождения денег под нового спеца - для них непозволительно, этой команде много лет, как говориться "на свадьбах друг у друга гуляли и детей крестили вместе".
Значит выход один - нужно посвящать время ручному тестированию, но и тут проблема... В их решении довольно много экранных форм, кнопочек, полей, а количество сценариев около трех сотен. То есть, если они втроем сядут прокликивать все самостоятельно - это займет пару-тройку дней, что является непозволительной роскошью, особенно с учетом того, что релизный цикл у них "раз в неделю".
Как говорится: Не можешь выполнить сам - делегируй! То есть найми других людей, которые будут заниматься этим за тебя. Вот только и тут экономика не складывается: Чтобы успеть все оттестировать хотя бы за те же два-три дня, нужно нанять 3 человек для работы "на износ", плюс каждого обеспечить рабочей станцией, платить налоги, страховки, итд... Если взять зарплату "на руки" среднего тестировщика примерно в 60к, то в сумме на троих со всеми отчислениями получается что-то около 300к в месяц (3,6млн в год), и это не считая побочные расходы на работу рекрутера/кадровика, больничные, отпуска и так далее.
Почему до сих пор не автоматизировали ручное тестирование?
Следующий вопрос, который возник - "Почему вы не автоматизировали ручное тестирование хотя бы тем же Selenium?"... И тут я узнал, что ребята пробовали им пользоваться, но все равно это крайне неудобный инструмент для них: нужно постоянно копаться в структуре страниц, выискивать идентификаторы, селекторы (которые еще до кучи динамические)... В общем они сделали ровно три теста, плюнули и забили - слишком сложно и долго. Ниже самый простой код, который проверяет погоду через гугл:
import time
from selenium import webdriver
driver = webdriver.Chrome()
driver.get("https://google.ru")
time.sleep(5)
textfield = driver.find_element_by_xpath("//input[@name='q']")
textfield.send_keys("погода на завтра")
time.sleep(5)
submit_button = driver.find_element_by_xpath("//div[@jsname='VlcLAe']//input[@class='gNO89b']")
submit_button.click() # После нажатия на кнопку должны появиться результаты поиска
time.sleep(5)
driver.quit()Вроде все читаемо и понятно, но другому разработчику, который взял тест за другим в поддержку, очень сложно понять что значит вот эта строчка:
"//div[@jsname='VlcLAe']//input[@class='gNO89b']"И это еще половина беды - у них в решении есть свое Windows-приложение, конфигурация для 1С + мобильные приложения, а все это в принципе не поддерживается Selenium-ом...
По их словам они вроде нашли какое-то решение, которое называется pyWinAuto, но вот незадача: С ним тоже все не так просто, а еще оно с 2018 года не обновляется... да и версия "0.6.8" (то есть даже еще не первый релиз) - не внушает никакого доверия.
Как в итоге автоматизировали ручное тестирование?
Я уже несколько лет занимаюсь автоматизацией сторонних приложений под Web и Windows и знаю, что есть специализированные инструменты, которые позволяют сделать автоматизацию пользовательских интерфейсов в разы проще. Называются такие инструменты: RPA-платформы, или "роботы". Используя эти инструменты достаточно просто мышкой выбрать элемент, а все остальное будет настроено автоматически:
Сам подберется точный селектор, так же сформируется "неточный" селектор (который предполагает, что искомый элемент может измениться: поменять свою позицию, какие-то параметры). Настройка взаимодействия с пользовательскими интерфейсами производится в виде специальных блоков действий: Прочитать текст, Ввести текст, Выбрать из списка, Установить/Снять флажок, Проверить наличие элемента интерфейса, Нажать (на самом деле действий гораздо больше, но не будем на этом заострять внимание).
Чтобы было понятнее, вот простой пример настройки робота, который подключается к 1С, вводит поля, нажимает кнопку и получает результат из поля:
Что касается мобильных приложений - некоторые RPA решения имеют готовые инструменты и инструкции как можно автоматизировать взаимодействие с ними. Чаще всего это делается либо с помощью специальных прослоек/эмуляторов, либо с помощью технологий Computer Vision.
А где же само тестирование?
Логичный вопрос для всех, кто сталкивался с такими инструментами - а как же реализовать нормальное тестирование? Это все вручную нужно писать, всякие там условия, куда-то что-то записывать?
Ответ такой: В обычных RPA именно так - все это нужно делать своими руками на авось. Но в особо продвинутых платформах есть готовые решения по тестированию. Дальше мы рассмотрим именно то решение, которое я предложил команде разработки, и которое им очень понравилось: UiPath Test Suite.
Важно понимать, что само решение разбито на несколько составных частей:
UiPath Studio
Студия разработки (очень похожая на Microsoft Visual Studio), в которой можно разрабатывать сценарии для работы с любыми Windows и Web-приложениями, а так же составлять сценарии тестирования по разным фреймворкам. Например, по умолчанию студия предлагает составлять BDD-тесты, состоящие из блоков:
Given - Что дано (подготовка окружения, запуск нужных приложений)
When - Непосредственное выполнение тестируемого сценария
Then - Проверка результатов выполнения
При этом для проверки значений есть уже готовые действия, которые регистрируют результат выполнения в интерфейсе, похожем на интерфейс тестирования Microsoft Visual Studio. Особо приятно то, что после выполнения тестов вы можете увидеть реальное покрытие ваших сценариев. И если вы видите, что не все ветки вашего сценария были затронуты тестовыми данными - стоит задуматься и добавить больше вариантов для проверок. Ведь неоттестированная ветка сценария = потенциальный сбой в работе ваших систем.
Кроме того, есть возможность загрузить целые наборы данных и запустить Data-Driven тестирование, получив результаты выполнения по каждому варинату, после чего повторить тестирование по тем вариантам, которые дали сбои. Здесь важно отметить, что работа с наборами данных - встроенная фича, вам не нужно реализовывать их загрузку, перебор и фильтрацию самому.
UiPath Robot
Приложение, которое может быть запущено на отдельно стоящем компьютере/сервере и выполнить всё тестирование не требуя непосредственного участия разработчика (зачем тратить драгоценное время на ожидание выполнения тестов на своей машине, если это можно сделать на другой?)
UiPath Orchestrator
Серверное ядро всей RPA-платформы. Здесь можно управлять роботами, планировать запуск тестов по расписанию, запустить их вручную из интерфейса и по команде через API, а так же наблюдать за ходом выполнения и анализировать результаты тестирования.
UiPath Test Manager
Так как оркестратор изначально - инструмент для управления роботами, использовать его для регулярного мониторинга результатов выполнения тестов является немного неудобным решением. Поэтому есть специальная отдельная точка входа, которая дает удобный интерфейс, понятный любому человеку, который занимается тестированием.
Очень важные и приятные дополнения: UiPath Test Manager может быть интегрирован с разнообразными ALM (например, с Jira), что позволит прокидывать требования из бэклога Jira напрямую в Test Manager, привязывать их к конкретным тестам в UiPath Studio, а все найденные ошибки во время тестирования - отправлять обратно в Jira.
Что там с экономикой?
Посмотрев на такое серьезное решение становится понятным, что оно просто не может быть бесплатным, и это правда. Помимо самой студии для разработки и роботов для выполнения тестов, необходимо иметь серверные компоненты (UiPath Orchestrator и UiPath Test Manager), которые в свою очередь могут быть установлены как на ваших мощностях, так и в облаке UiPath. Интересно то, что стоимости вариантов приобретения (On-Prem и Cloud) примерно одинаковы, но приобретая облако вам не нужно заниматься выделением серверов, установкой, настройкой и обслуживанием серверных компонент.
В целом по затратам на приобретение облачного решения с возможностью использования на ваших компьютерах одной студии и одного робота (который может смело заменить трех ручных тестировщиков) - выходит сопоставимо со всеми затратами на одного тестировщика (учитывая прямые и косвенные). Конечно, нужно учесть, что придется вложить время в то, чтобы настроить тестовые сценарии и это делается не за пять секунд, но, как показывает практика, время настройки одного сценария в студии сопоставимо со временем, которое вы потратите на то, чтобы объяснить "что нужно делать" обычному стажеру.
А если учесть то, что ваш робот никогда не опоздает на работу, не уйдет на больничный, в отпуск, не потребует повышения зарплаты, не уйдет к конкурентам и с удовольствием поработает ночью и на выходных - получается, что выгода от применения роботов в тестировании неоспорима.
Но неужели соединять визуальные кубики удобнее, чем писать понятный код текстом?
Конечно, здесь можно задуматься и сказать, что в этом случае для экономии можно потратить больше времени и сделать такие тесты кодом на питоне с использованием соответствующих решений, но с другой стороны нужно задаться вопросом: "кто и как это будет поддерживать, когда разработчик таких тестов уйдет?".
Сколько людей - столько и мнений. Честно признаться, когда я сам только знакомился с миром RPA - был большим скептиком и громко смеялся над словом "роботизация". Но когда я начал серьезно использовать инструмент и увидел, что за один день я делаю столько работы, сколько раньше делал за несколько дней - понял, что это реально классный инструмент.
Кроме того, создавая подобные тесты своим программным кодом - вы не получаете автоматом возможность настраивать автозапуски на других компьютерах, не имеете централизованного хранения логов, лишаетесь статистики покрытия кода тестами, не видите статистику по выполнению за определенный период в едином удобном интерфейсе. Конечно, все это можно реализовать методом проб и ошибок перебирая готовые бесплатные решения за очень большое время. Но будет ли это реально дешевле, если потраченное время выразить в зарплате разработчиков, которые будут заниматься этим вместо разработки самого продукта?
Мое настроение по поводу преимущества использования готового решения от UiPath разделила команда, о которой шла речь в самом начале статьи - они меньше чем за неделю освоили инструмент, научились делать тесты и встроили их в CI/CD пайплайн Jenkins: после коммита в релизную ветку запускается проверка тестов роботами и в случае успешного прохождения всех тестов - релиз публикуется на сервере приложений. То есть они даже не запускают роботов руками и не смотрят результаты, если не произошло ни одного негативного результата. А если это случилось - быстро получают доступ к отчету и исправляют ошибки в кратчайшие сроки.
А вы уже пробовали перевести свое ручное тестирование на рельсы автоматизации с использованием роботов? Если пробовали - с помощью какого решения и какой результат вы получили?
