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


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