Home

Привет! В этом посте мы хотим рассказать о том, как мы в МКБ построили тестирование. 

Про наши процессы, путь новичка, технологии, планы и про то, почему скрам-команду на самом деле можно собрать не из 8-10, а из 20-40 человек — под катом.

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

Каждая команда прокачивает практики тестирования самостоятельно. Да, на уровне банка у нас задекларированы определенные процессы, но, как говорил Барбосса в «Пиратах Карибского моря», кодекс — это просто свод указаний, а не жёстких законов.

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

Точно так же инициатива и экспертиза команды помогают ей самой решать, сколько именно специалистов по тестированию нужно взять для продуктивной работы. Например, в команде, занимающейся ипотекой, 22 человека (из которых тестировщиков — 6), а вот в команде нецелевых кредитов и кредитных карт — 46 (из них 7 тестеров).

Путь новичка

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

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

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

Итак, у новичка всё есть и всё работает, приступаем к задачам.

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

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

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

С чем и как работаем

Общие и привычные инструменты:

• TestRail — система тест-менеджмента;

• Jira — баг-трекер;

• Confluence — база знаний;

• Собственные корпоративные мессенджер и «звонилка».

Функциональное тестирование:

• Сниффер трафика — Fiddler, WireShark;

• Базы данных — PLSQL Developer, Oracle SQL Developer, dbeaver, DataGrip, SQL Server Management Studio, pgAdmin, Redis Client;

• SSH — Putty, WinSCP;

• Web-сервисы — Postman, SOAP UI, Swagger;

• NotePad++ с плагинами, например, Xml Tools, Json Viewer;

• Симуляция мобильных приложений — Android Studio, Xcode;

• Логи — ELK.

Специализированные инструменты конкретных видов тестирования:

Автоматизированное тестирование:

• Автоматизированное тестирование iOS — Swift + XCTest;

• Автоматизированное тестирование Android — Kotlin + Espresso;

• Автотесты web-приложений — Java + Selenide;

• CI — GitLab;

• Отчёты — Allure;

• IDE — IntelliJ IDEA;

• Сборщик пакетов — Maven, Gradle.

Нагрузочное тестирование:

• Apache Jmeter;

• Самописные системы построения отчетов.

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

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

Планы

Одна из наших основных целей — выстроить в МКБ настоящий, полноценный fullstack QA. Для этого надо будет весьма и весьма масштабно перестроиться. 

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

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

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

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

А ещё мы сейчас заканчиваем разворачивать сразу несколько новых контуров нагрузочного тестирования. К концу года постараемся создать контур нагрузочного тестирования и для систем ДБО. Само нагрузочное тестирование внедрим в общий релизный цикл и будем прогонять нагрузку при старте регрессионного тестирования.

Параллельно с этими работами решаем ряд проблем, связанных с автоматизированным попиксельным тестированием. Уже написаны около 80 автотестов, умеющие снимать скриншоты и автоматически находить расхождения в верстке и дизайне.

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

Собственно, это всё, что мы хотели вам рассказать, если вдруг что-то упустили и вам интересны другие аспекты работы QA в МКБ — пишите в комментариях, расскажем подробнее. 

Обсудить в форуме