Tladianta. Сервис по автоматизированному тестированию в Росбанке

    06 октября

Всем привет! Меня зовут Антон Епишин, и я продолжаю наш небольшой цикл статей про автоматизированное тестирование в Росбанке.

В прошлый раз Юрий Скворцов рассказал про один из инструментов, который помогает нам быть уверенными в качестве предоставляемого фреймворка Tladianta.
Сегодня же мы затронем процесс, который мы построили за последние 9 месяцев в условиях ИТ-трансформации банка, распределённой команды, а также COVID-изоляции (если считать время с начала подготовки концепции и заканчивать первыми успешными результатами).

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

  • степень "зрелости" ручного тестирования на проекте;
  • технологий, используемых в процессе разработки продукта;
  • целей внедрения автоматизированного тестирования и вовлечения команды;
  • компетенции непосредственных исполнителей
    и т.д.

Недостаточная проработка этих моментов может привести к:

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

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


Итак, вернёмся для начала в ноябрь-декабрь 2019 года.


Legacy

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

Вроде всё неплохо, но:

  • До 80% работ выполнялось сотрудниками вендора, сотрудники отдела зачастую занимались приёмкой Pull-requests и могли быть оторваны от реального процесса. Вовлеченности это не помогало. Собственно, как и развитию.
  • «Фреймворк 2018» изначально был реализован с архитектурой, при которой работа нескольких независимых команд попросту невозможна из-за постоянного риска сломать кому-либо их набор тестов. Технологии остались в 2018 году без возможности что-то улучшить или исправить (решалось только работой в разных ветках без возможности сделать даже merge).
  • В отделе осталось формально 2 человека – 1 в Москве и 1 в Нижнем Новгороде.
  • Каждая команда может выбирать свой стек технологий и языки. «Зоопарк» технологий виднелся уже буквально на следующей улице.
  • В 2020 и далее планировался запуск большого числа команд.

Возникают понятные вопросы: как сделать автоматизацию действительно полезной? Как обеспечить развитие? Как помочь всем?

Двигаемся к цели

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

Далее, подключились (и доработали со своей стороны) к концепции «тестирования как сервиса», предложенную нашими коллегами. Последним решили вопрос что делать с «зоопарком» по факту до момента его действительного появления.
Так, несколько непоследовательно, но мы пришли к понятию «Автоматизированное тестирование как сервис». Наша команда стала «Центром экспертизы» с функциями:

  • Разработка и развитие Core-фреймворка Tladianta;
  • Внедрение практик автоматизированного тестирования по запросам команд:
    Внедрение и сопровождение инструментов АТ;
    Обучение и консультации по развитию сотрудников в направлении АТ;
    Вендор менеджмент по АТ;
    Помощь при проведении технических интервью;
  • Старт и развитие темы с «Chapters&Guild Автоматизированного тестирования». Тут мы стали пилотом по банку. О том, что это, как и в чем помогает – в следующих статьях, тема достаточно обширная.

Под данную концепцию было согласовано расширение штата ЦК АТ с 2 человек до 6 (4 в Москве и 2 в Нижнем) и в дальнейшем до 9 человек, каждому из которых досталось по одному «основному» направлению и 1-2 «резервных».


Основные шаги


Далее на каждом из шагов схематически представлен % предполагаемой активности как со стороны обратившейся команды, так и нашего отдела


1. Определение потребности в автоматизации

Важная активность, которая позволяет перейти из состояния «мы хотим автоматизированное тестирование» к «мы хотим автоматизированное тестирование, потому что… »
В основном чаще всего болит где?

  • Срываем сроки релизов
    Длительный регресс.
    Мало людей на ручных тестах.
    Нет данных для адекватной оценки качества релиза.
    Долго проверяем исправления.
  • Качество самого ПО :)
    Долго ищем дефекты.
    Проверяем только "стандартный" функционал системы — без учета доработок под банк
    Очень много проверок интеграционных взаимодействий.
    Люди – все мы иногда ошибаемся, ленимся.
    Нужно проверять небольшую части функционала на большом объёме данных. Или проверки сложно делать «вручную»
    Все это приводит к мысли: «а не внедрить ли нам АТ?».

Мы составили небольшой чек-лист вопросов, ответы на которые помогают понять необходимость внедрения АТ. Чем больше положительных ответов, тем с большей вероятностью автоматизированное тестирование поможет именно вам:


Опросник

Итог: команда в общем понимает, для чего им автоматизированное тестирование. ЦК АТ имеет точку старта в виде заполненного опросника. Ну а если проблемы с этим, тогда заполняем его вместе на следующем шаге.


2. Обращение в ЦК АТ


Проводится стартовая встреча с командой, на которой:

  • Обсуждаем или до-заполняем опросник;
  • Мы рассказываем о доступных возможных сервисах:
    Миграция/актуализация существующих автоматизированных тестов при наличии автоматизатора в команде;
    Поиск сотрудника (автоматизатора) в команду;
    Привлечение подрядчика;
    Обучение специалистов команды;
    Старт процесса автоматизированного тестирования с нуля;
  • (Опционально) Договариваемся о проведении стартового рассказа о нас и Tladianta Framework с сессией вопросов/ответов со всеми заинтересованными сотрудниками команды.

Итог: Готов список дальнейших шагов, понятный и нам, и команде.


3. Технический анализ системы

  1. Анализ инструментов
    На данный момент Tladianta Framework использует в своих модулях возможности следующих инструментов и библиотек (с привязкой к языку Java):
  • Selenium WebDriver;
  • Appium;
  • MF LeanFT (в части desktop-тестирования);
  • RestAssured.

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

  • Нельзя считать значение из текстового поля внутри приложения;
  • Нельзя выполнить клик по необходимому элементу;
  • Приложение вообще не запускается и/или выдает ошибку;
    и т.д.

Для определения данных проблем и выработки стратегии по дальнейшей работе специалистами отдела АТ проводится исследование совместимости инструментов автоматизации и тестируемого приложения. Результатом данного исследования является заключение о возможности применения инструментов Tladianta. Возможные варианты:

  • Полная совместимость;
  • Возможно расширение функционала Tladianta;
  • Расширение функционала Tladianta не рационально — предлагается альтернативное решение.
    Тут важно отметить, что нет цели отправить всех в один инструмент. Это бессмысленно и бесполезно. Критичны два момента – чтобы инструмент максимально подходил для решения задачи и чтобы не дублировал уже существующие решения в банке. Об этом мы еще раз поговорим в статье про Chapters&Guild.


2. Анализ системы и стендов тестирования
Достаточно часто причинами итоговой нестабильности разработанных автоматизированных тестов являются не ошибки в разработке непосредственно самих тестов. Это могут быть моменты, незаслуженно забытые или не проанализированные до старта разработки тестов. Пара примеров (полный список и варианты решений в эту статью не влезут. Если будет интересно – можем рассказать отдельно):

  • "Общий" тестовый контур для всех. Автоматизированный тест — это скрипт, который на исчезновение нужного пользователя (которого кто-то вдруг изменил/удалил) отреагирует одинаково — ошибкой. Можно усложнять скрипты проверками и вариативностью, увеличивая трудозатраты и сроки, но наиболее правильный вариант — отдельный контур для автоматизированного тестирования. Можно уже на этом этапе предложить и зафиксировать методику дальнейшей работы, позволяющую автоматизированным тестам минимально зависеть от вмешательства "со стороны".
  • Возможность доработки системы под автоматизацию. В случае, если мы имеем дело с "коробкой", разработанной сторонней компанией — внести изменения крайне сложно. Но вот если разработка ведется внутри банка, то возможно сделать некоторую работу, которая, с одной стороны, сильно облегчит автоматизацию и дальнейшую поддержку, с другой — скорее всего, не будет являться большими трудозатратами для самих разработчиков.

Речь в первую очередь о локаторах элементов. Локатором является некий путь в системе по которому можно найти данный элемент. Сравним два варианта (несколько гипертрофированных для наглядности):

  • Достаточно лаконичное значение

@ElementTitle("Войти")

@FindBy(xpath = "//button[@value='Войти']")
public Button enterButton;

  • Xpath, который даже не поместился на 1 экран
    @ElementTitle("Ограничения по счету")
    @FindBy(xpath = "//hierarchy/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.ScrollView/android.widget.LinearLayout/android.view.ViewGroup[4]")
    public MobileEditElement accountRestrictions;

Достаточно просто выбрать вариант, который будет предпочтителен и для разработки, и для поддержки.

Итоги: Определены используемые инструменты
Сформированы рекомендации по подготовке стенда к тестированию (или методики тестирования)
Сформированы рекомендации к возможной доработке самого тестируемого приложения


4. Подготовка тест-кейсов и оценок

'Что бы автоматизировать что-то нужное, надо сначала описать это нужное. А у нас тест-кейсов нет' (с)
Вольная интерпретация известной цитаты из хорошего мультика.
К сожалению, нередки истории, когда автоматизированное тестирование уже давно в планах, но вот состояние «ручного» тестирования оставляет желать лучшего. В итоге либо автоматизируем не тот функционал, что нужно, либо ловим кучу ошибок, либо вынуждены постоянно переписывать один и тот же кейс. В итоге время утекает, бюджет давно потрачен, а пользы – ноль.


1. Актуализация тестовой модели
Тестовая модель — это модель тестируемой системы, на основе которой разрабатываются сценарии. Модели строятся на основе требований или ожидаемого поведения системы.

Зачем нужна модель:

  • оценивать полноту покрытия требований тест-кейсами;
  • контролировать изменения требований для своевременного обновления тест-кейсов;
  • приоритезировать тест-кейсы;
  • управлять объемом тестирования для каждого этапа тестирования;
  • определять связи между функциями системы;
  • рассчитывать регресс.


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

  • Стабильный функционал (не изменяются, либо редко и незначительно);
  • Есть необходимость проверять часто;
  • Большое число ошибок на продуктивной среде;
  • При необходимости использовать тестовые данные – понятно откуда их брать и/или как быстро сгенерировать
    На этом этапе также выбирается и детализируется небольшой набор кейсов, который реализуется нами (1-5 кейсов, в зависимости от объема). Это будут примеры и «база» для всех остальных.


3. Составление HLE-оценки
Для выбранного набора тест-кейсов специалистом отдела АТ формируется экспертная оценка в днях и с примерным бюджетом.

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

Итог: Сформирован и определен общий объём работ, выбраны тест-кейсы для реализации силами отдела АТ, предоставлена HLE-оценка.


5. Подбор сотрудника в команду

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

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

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

Основные варианты:


1. Обучение сотрудника команды

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

2. Подбор нового сотрудника


  • Совместно с командой составляем профиль поиска и определяем уровень желаемого специалиста
    Нельзя не отметить то, что благодаря Tladianta, можно сразу сформировать необходимый технический минимум. Все технологии и инструменты известны заранее.;
  • Специалист отдела АТ будет присутствовать на технической части собеседования с кандидатом, формируя по итогам общения развернутый итог;
  • После успешного найма, Отдел АТ может помочь с:
    Обучение Tladianta и теории АТ;
    Составление ИПР (индивидуальный план развития) и курирование развития сотрудника.


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

  • Совместно с командой формируется ТЗ на работы;
  • Определяются моменты, связанные с дальнейшей поддержкой (после выполнения работ подрядчиком);
  • На основе ТЗ подготавливается HLE-оценка, представляющая собой экспертную оценку в m/d и итоговом бюджете на данный объем работ;
  • Запрос предложений у подрядчиков, с которыми у банка заключены договоры. Выбор, заключение задания на работы;
  • Помощь при приёмке. Итоговые результаты передаются полностью в команду.

 

6. Внедрение Tladianta Framework (или иного выбранного инструмента)


Вот уже 6-й шаг и только сейчас мы доходим непосредственно до кода и написания автотестов. Что же тут происходит:


Доработка под уникальные особенности проекта и разработка базового набора тестов (15-20 m/d) или разработка фреймворка на выбранном инструменте
На данном этапе специалистом ЦК АТ производятся следующие работы:


Создание проекта на базе Tladianta или иного инструмента;

  • Реализация вспомогательных модулей под целевую систему (в рамках необходимого и достаточного объема, ограниченного выбранным начальным набором тестов);
  • Реализация и отладка автоматизированных тестов по отобранным ранее сценариям;
  • Консультации со специалистами команды, связанные с бизнес-логикой тестируемой системы

На данном этапе крайне важен оперативный отклик от команды, а также стабильность тестируемой системы и ее функционала. Планируемые трудозатраты специалиста ЦК АТ — не более 20 m/d

Встраивание тестов в процесс непрерывной интеграции (< 2-3 m/d)
Один из основных плюсов проведения автоматизированного тестирования — возможность автоматически запустить произвольный набор тестов (после изменения кода проекта разработчиком/по времени) хоть глубокой ночью и на любом числе виртуальных машин. Таким образом, уже с утра может быть получен отчет о статусе проведенного тестирования системы. Проведя анализ данного отчета, специалист по автоматизации (или функциональный тестировщик/аналитик) выносят возможные дефекты в JIRA

Итог: Подготовлен базовый набор автоматизированных тестов, которые выполняются посредством запуска задания в Jenkins. Набор готов к передаче


7. Обучение и передача


Формально финальный для нас, но стартовый самостоятельный шаг для команды.


1. Передача проекта. В рамках данной активности в команду передается следующий набор данных:

  • Проект, размещенный в BitBucket;
  • Ссылка на сконфигурированное задание в Jenkins;
  • Инструкция по фреймворку (Tladianta или иному разработанному);
  • Ссылка на проект в Jira (для возможности формирования запросов);
  • Ссылка на обучающие материалы.


2. Обучение. Проводится специалистом Отдела АТ. Основные темы:

  • Setup&Configuration;
  • Create&Run;
  • Debug&Modification.

Онлайн-обучение, которое покрывает только функционал Tladianta (или иного фреймворка). Полноценное покрытие таких тем как — теория автоматизированного тестирования, инструменты автоматизированного тестирования (Selenium, Maven, Git, e.t.c), Java, в рамках данной активности не затрагиваются. Это возможно организовать отдельно.
Также, кроме онлайн-версии, доступны оффлайн-видео, размещенные в Confluence.

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

  • Консультации и поддержка, которая касается возможностей Tladianta Framework;
  • Возможность влиять на развитие Tladianta Framework и его возможности — посредством предложений о новых доработках;
  • Со стороны отдела АТ — предоставление новых возможностей и гарантия совместимости (новые версии модулей Tladianta Framework);
  • Участие в Community для обмена навыками и наработками (встречи, мастер-классы могут проводиться как силами отдела АТ, так и силами заинтересованных команд).

Итог: Команда развивает направление автоматизированного тестирования у себя, при необходимости — получает поддержку со стороны Отдела АТ. Вовлечена в общебанковское Community и обменивается знаниями с остальными командами

Вместо послесловия

Статья получилась достаточно обширная в плане «теории» и выстраивания процесса. Данный сервис уже прошел обкатку и смог решить вопросы, о которых говорилось в самом начале – упрощение «входа», сокращение возможны ошибок при запуске, быстрая миграция тех тестов, что были разработаны ранее и т.д. Но мы прошлись еще совсем по верхам и оставили часть интересной информации для следующих статей, в случае, если это будет интересно и действительно сможет кому-то помочь. На очереди:

  • Информация про наш фреймворк Tladianta;
  • Правила и рекомендации по подготовке тест-кейсов к автоматизации;
  • Метрики автоматизированного тестирования, или Как понять, что вы движетесь в правильном направлении;
  • Как проводить анализ совместимости инструментов и тестируемого приложения (и ничего при этом не забыть);
  • И, конечно же, одно из самых важных – как в сложной ИТ-компании и при условии множества команд не создать «зоопарк» подходов и инструментов по АТ. Тут мы поговорим про Chapters&Guild.

Подписка на новости