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

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

В прошлый раз Юрий Скворцов рассказал про один из инструментов, который помогает нам быть уверенными в качестве предоставляемого фреймворка 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-й шаг и только сейчас мы доходим непосредственно до кода и написания автотестов. Что же тут происходит:

1. Доработка под уникальные особенности проекта и разработка базового набора тестов (15-20 m/d) или разработка фреймворка на выбранном инструменте
   На данном этапе специалистом ЦК АТ производятся следующие работы:
   
   • Создание проекта на базе Tladianta или иного инструмента;
   • Реализация вспомогательных модулей под целевую систему (в рамках необходимого и достаточного объема, ограниченного выбранным начальным набором тестов);
   • Реализация и отладка автоматизированных тестов по отобранным ранее сценариям;
   • Консультации со специалистами команды, связанные с бизнес-логикой тестируемой системы
     На данном этапе крайне важен оперативный отклик от команды, а также стабильность тестируемой системы и ее функционала. Планируемые трудозатраты специалиста ЦК АТ — не более 20 m/d
2. Встраивание тестов в процесс непрерывной интеграции (< 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.