Как мы в "Приватбанке" пришли к разработке своей системы TestManager

Меня зовут Вадим Гулич, я руководитель департамента тестирования Front-end и Mobіle в «ПриватБанке». Имею опыт в тестировании более 7 лет.

Эта статья посвящена решению проблемы, которая возникает во многих компаниях в процессе управления тестированием и выбора инструментария. Будет полезна QA, Team Lead и всем участникам разработки, которые хоть как-то вовлекаются в тестирование.

В самом начале, когда тестирование только развивалось в «ПриватБанке», а библией тестирования была книга Романа Савина «Тестирование DOT COM», мы использовали TestLink — бесплатное open source решение, мастодонт среди современных TMS. Но тестирование не стояло на месте, и гибкие методологии разработки все ближе подкрадывалась в наши ІТ-ряды. Тогда и ушли громадные и трудоемкие в поддержке тест-кейсы, за что спасибо Agile (принцип 2: «Работающий продукт важнее исчерпывающей документации»), и устаревший TestLink просил замены.

Анализ тестирования

Когда мы проанализировали, что изменилось и чего нам недостаточно для работы, обнаружили ряд артефактов, которыми оброс наш процесс тестирования:

TestLinkхранилище тест-кейсов
прогон тест-кейсов
метрики по регрессу
Google Sheets критический функционал
чек-лист по тестированию новых фич
дополнительная информация по проекту
статистика по работе
метрики по проекту
постановка целей по SMART
Google Docsотчет о тестировании
Система управления проектами и задачамибаг-репорты
работа с задачами версии/патча
Внутренние комплексы банкасотрудники
внутренние метрики и другое

В целом не так много артефактов, если говорить о небольшой команде и 1–2 проектах. Но когда в команде тестирования более 70 человек, а проектов больше 200, то картинка становиться не такой радужной и грамотно управлять всем этим смог бы только Чак Норрис. Но он настолько крут, что деплой в прод проходит без тестирования, у него нет регрессионного тестирования, есть только прогрессивное :)

У нас было желание что-то менять и этим помочь тестированию. Собрав команду инноваторов с горящими глазами, мы начали brainstorming на тему «лучшая TMS для тестировщиков».

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

Что у нас из этого вышло (краткий список без детализации):

ФункционалПроблематика
Создание чек-листа по новому функционалу отсутствие информации о глубине тестирования задач версии
Доступ к чек-листу в режиме просмотра для заинтересованных лицотсутствие консолидированной информации
Автоматическая генерация отчета о тестировании версии/патчаручное копирование результатов из чек-листов и других артефактов в отчет
Перенос проверок по чек-листу нового функционала в бэклогудаление проверки после переноса задачи в версии
Чек-лист по критическому функционалусложное ранжирование проектов; чек-листы хранятся в Google-таблицах
Перенос проверок по чек-листу нового функционала в чек-лист по критическому функционалусложная актуализация покрытия регрессионного набора кейсов
Добавление теговотсутствует детализация тестовых сценариев и удобная фильтрация для выбора тестовых наборов
Авторизация LDAPбанковская система авторизации по LDAP
Хранение отчетов о тестированииотчеты по тестированию хранятся на Google Drive
Автоматическое проставление статусов и затраченного времени по задачам в PPработа со статусами задач в разных комплексах
Профиль проектовотсутствие единого полного хранилища информации о тестируемом проекте; сложность сбора метрик
Заведение ошибок из TMSработа с задачами в разных комплексах
Получение информации по прогону автотестов из Jenkinsинформация по результатам тестирования отображается в разных комплексах, нет связки в мануальных/автоматизированных кейсах
Дополнительно
Возможно развернуть систему на своих мощностях и ее администрирование
Интеграция с внутренними комплексами
Поддержка инструмента, чтобы быть уверенным в «завтрашнем дне» (зависимость от изменения условий, уход с рынка и так далее)

Определив функционал, который решал бы наши проблемы, мы принялись проводить анализ внешнего рынка уже существующих систем. Для этого были выбраны следующие системы*:

HP Quality CenterXQualXStudio
Agile Central LabsPractiTest
Squash TMTest Collab
QMetry Test ManagementQACoverage
QACompleteStryka
TestRailTestMonitor
Test PADSitechco
TestLodgeTestLink

*На текущий момент появились новые и есть достойные внимания, можно ознакомиться по ссылке.

Но, к сожалению или к счастью, ни одна из систем не покрыла требования, а те, что хоть как-то были близко к нашему набору желаемых фич, кусались в цене и были завязаны на свой «зоопарк» систем. Оценив все за и против, мы решили написать свою TMS под названием TestManager.

Начало пути TestManager. Пилот

Путь был не прост, первая версия была написана все теми же инноваторами, разворачивалась на локальном сервачке, обкатывали этот инструмент часть специалистов по тестированию департамента Front-end и Mobile. Была боль, были муки, но оно того стоило.

Боли и муки

Лого TestManager

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

Примером одной из таких болей стало удаление всего чек-листа после нажатия кнопки «сохранить». Причина — сессия обрывалась до момента завершения заполнения чек-листа, и запрос на сохранение не отрабатывал, сообщение об ошибке на фронт было только в мечтах, а последующее обновление страницы отображало пустоту чек-листа и души тестировщика. Если увидите седого тестировщика, есть вероятность, что это ветеран пилота по ТМ :)

В-третьих, перестройка, поддержка прошлых артефактов и работа в новых давались непросто.

Коллеги тяжело переживали все эти неприятные моменты, как говорится, все новое чуждо, а тут еще и инновационное. Мы прошли все 5 стадий эмоционального реагирования: отрицание, гнев, торг, депрессия и принятие. На каждой мы улучшали и улучшали продукт, было много фидбэка.

Как только поняли, что инструмент начал приносить пользу и тестировщики больше не зарывались в миллионах артефактов, приняли решение развивать этот инструмент и масштабировать на другие департаменты и команды.

Подготовив ряд презентаций по новому инструменту, указав проблематику/анализ рынка/решение и готовые результаты пилотного использования, мы получили approve от руководителя направления ІТ для выделения команды специалистов и его разработки. На этом этапе началась трансформация всего тестирования...

Коротко о самой системе TestManager

TestManager — это инструмент для управления тестированием на всех этапах борьбы за качество продукта: Testing, Quality Control, Quality Assurance.

Построена система на базе основного workflow по работе с проектами, которое обросло артефактами и другими активностями тестировщика.

Чек-лист новых доработок

Чтобы не проходить по всем узлам процесса тестирования и сопутствующему функционалу, выделю несколько интересных фич инструмента.

Это перерождение артефакта с Google Sheets, где описывали кейсы и проверки для задач, которые со временем терялись в системе управления проектами или аккаунтах почты.

Сейчас же это интерфейс с интеграцией для получения задач версии, удобная работа со статусами проверок, CKEditor, дополнительные поля и теги, что дали больше гибкости в описании проверки, заведение ошибок по определенному шаблону (чтобы для разработчиков не был каждый баг как ребус).

Актуализация критического функционала

В прошлом это Ctrl + С и Ctrl + V с одного чек-листа в Google Sheets в другой. Но, к сожалению, часто не было откуда сделать Ctrl + С, а понять статус актуализации можно было лишь после похода к мудрейшему тестировщику на проекте :)

В TestManager мы реализовали удобный функционал актуализации. В общей таблице всех версий (которые прошли процесс тестирования нового функционала) добавлен статус по ней.

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

Метрики по проектам

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

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

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

Еще есть фичи, которые остались за кадром, и много запланированных, но о них расскажу в следующей статье, если будет к этому интерес.

Итог

Из этого смелого пилота мы получили профит:

  • Систему управления процессом тестирования, которую можно кастомизировать под свои потребности.
  • Интеграцию с внутренними банковскими комплексами.
  • Единое хранилище тестовых артефактов проектов (а это более 200 проектов), которые доступно всем участникам разработки.
  • Фоновый сбор метрик всего процесса тестирования.
  • Баг-репорты в одном виде, что упрощает разбор ошибок командой разработки и не только.
  • Стандартизированное workflow по тестированию с учетом всех важных этапов.
  • Экономию времени на работу с артефактами.
  • И очень важно — опыт построения, внедрения и трансформации в тестировании.

Были ли трудности при запуске одной системы на такое количество проектов и команд? Да, были, но это совсем другая история...

Похожие статьи:
Ранее в сети уже появлялись слухи о международной версии смартфона Droid Turbo 2, который будет продаваться в США у Verizon Wireless - модели Moto X Force....
Как и ожидалось, во время вчерашней презентации, кроме новых смартфонов Nexus, компания Google анонсировала и планшет под названием Pixel C. Он,...
До вашої уваги дайджест навчальних програм для тих, хто починає свою кар’єру в ІТ. В цьому номері зібрані можливості, актуальні...
В этой статье я попытаюсь рассказать про принцип инверсии зависимостей (Dependency inversion principle, далее DIP). В статье будут упомянуты...
17 октября 2016 года в CyberBionic Systematics начнутся курсы для Frontend — как для новичков, так и для специалистов, уже имеющих некоторые...
Яндекс.Метрика