Как мы в "Приватбанке" пришли к разработке своей системы TestManager
Меня зовут Вадим Гулич, я руководитель департамента тестирования Front-end и Mobіle в «ПриватБанке». Имею опыт в тестировании более 7 лет.
Эта статья посвящена решению проблемы, которая возникает во многих компаниях в процессе управления тестированием и выбора инструментария. Будет полезна QA, Team Lead и всем участникам разработки, которые хоть как-то вовлекаются в тестирование.
В самом начале, когда тестирование только развивалось в «ПриватБанке», а библией тестирования была книга Романа Савина «Тестирование DOT COM», мы использовали TestLink — бесплатное open source решение, мастодонт среди современных TMS. Но тестирование не стояло на месте, и гибкие методологии разработки все ближе подкрадывалась в наши ІТ-ряды. Тогда и ушли громадные и трудоемкие в поддержке тест-кейсы, за что спасибо Agile (принцип 2: «Работающий продукт важнее исчерпывающей документации»), и устаревший TestLink просил замены.
Анализ тестирования
Когда мы проанализировали, что изменилось и чего нам недостаточно для работы, обнаружили ряд артефактов, которыми оброс наш процесс тестирования:
| TestLink | хранилище тест-кейсов |
| прогон тест-кейсов | |
| метрики по регрессу | |
| Google Sheets | критический функционал |
| чек-лист по тестированию новых фич | |
| дополнительная информация по проекту | |
| статистика по работе | |
| метрики по проекту | |
| постановка целей по SMART | |
| Google Docs | отчет о тестировании |
| Система управления проектами и задачами | баг-репорты |
| работа с задачами версии/патча | |
| Внутренние комплексы банка | сотрудники |
| внутренние метрики и другое |
В целом не так много артефактов, если говорить о небольшой команде и
У нас было желание что-то менять и этим помочь тестированию. Собрав команду инноваторов с горящими глазами, мы начали brainstorming на тему «лучшая TMS для тестировщиков».
В процессе генерировали идеи ключевого функционала, который должен спасти нас от множества артефактов и рутины, упростить менеджмент в тестировании, формализовать workflow и в то же время быть гибким.
Что у нас из этого вышло (краткий список без детализации):
| Функционал | Проблематика |
| Создание чек-листа по новому функционалу | отсутствие информации о глубине тестирования задач версии |
| Доступ к чек-листу в режиме просмотра для заинтересованных лиц | отсутствие консолидированной информации |
| Автоматическая генерация отчета о тестировании версии/патча | ручное копирование результатов из чек-листов и других артефактов в отчет |
| Перенос проверок по чек-листу нового функционала в бэклог | удаление проверки после переноса задачи в версии |
| Чек-лист по критическому функционалу | сложное ранжирование проектов; чек-листы хранятся в Google-таблицах |
| Перенос проверок по чек-листу нового функционала в чек-лист по критическому функционалу | сложная актуализация покрытия регрессионного набора кейсов |
| Добавление тегов | отсутствует детализация тестовых сценариев и удобная фильтрация для выбора тестовых наборов |
| Авторизация LDAP | банковская система авторизации по LDAP |
| Хранение отчетов о тестировании | отчеты по тестированию хранятся на Google Drive |
| Автоматическое проставление статусов и затраченного времени по задачам в PP | работа со статусами задач в разных комплексах |
| Профиль проектов | отсутствие единого полного хранилища информации о тестируемом проекте; сложность сбора метрик |
| Заведение ошибок из TMS | работа с задачами в разных комплексах |
| Получение информации по прогону автотестов из Jenkins | информация по результатам тестирования отображается в разных комплексах, нет связки в мануальных/автоматизированных кейсах |
| Дополнительно | |
| Возможно развернуть систему на своих мощностях и ее администрирование | |
| Интеграция с внутренними комплексами | |
| Поддержка инструмента, чтобы быть уверенным в «завтрашнем дне» (зависимость от изменения условий, уход с рынка и так далее) | |
Определив функционал, который решал бы наши проблемы, мы принялись проводить анализ внешнего рынка уже существующих систем. Для этого были выбраны следующие системы*:
| HP Quality Center | XQualXStudio |
| Agile Central Labs | PractiTest |
| Squash TM | Test Collab |
| QMetry Test Management | QACoverage |
| QAComplete | Stryka |
| TestRail | TestMonitor |
| Test PAD | Sitechco |
| TestLodge | TestLink |
*На текущий момент появились новые и есть достойные внимания, можно ознакомиться по ссылке.
Но, к сожалению или к счастью, ни одна из систем не покрыла требования, а те, что хоть как-то были близко к нашему набору желаемых фич, кусались в цене и были завязаны на свой «зоопарк» систем. Оценив все за и против, мы решили написать свою 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 по тестированию с учетом всех важных этапов.
- Экономию времени на работу с артефактами.
- И очень важно — опыт построения, внедрения и трансформации в тестировании.
Были ли трудности при запуске одной системы на такое количество проектов и команд? Да, были, но это совсем другая история...
