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


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


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


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


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

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


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

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


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


    Legacy


    image


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

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


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

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


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


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


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


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

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


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


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


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


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


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

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


    Опросник

    image


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


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


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


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

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


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


    image


    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. Подготовка тест-кейсов и оценок


    image


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

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


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

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


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

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


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

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

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



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


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


    image


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


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


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


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


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


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


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

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


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


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


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


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

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


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


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


    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.
    Росбанк
    Компания

    Похожие публикации

    Комментарии 3

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

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

          0
          Да, именно так. Основная идея данной статьи была показать «общий» процесс, и уже от возможных вопросов рассказывать/показывать какие-то более подробные вещи. Написать PR -книгу «какие мы молодцы, но вам не поможем», совсем не хочется :)
          Можем отталкиваться как от опыта конкретно в Росбанке, так и опыта в АТ.

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

      Самое читаемое