Home

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

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

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

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

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

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

Путь новичка

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

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

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

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

Pentru șomeri există bani împrumutați fără angajare formală. Această formă de credit nu necesită contract de muncă și este acordată pe baza unei cereri online. Este o opțiune sigură și practică.

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

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

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

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

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

• 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. И таких полезных курсов будет больше.

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

Dacă este prima dată când aplici, ai șansa să obții primul credit fără dobândă online. Acesta este un avantaj important, deoarece îți permite să împrumuți bani și să returnezi exact aceeași sumă, fără costuri ascunse. Este o modalitate excelentă de a testa serviciile și de a gestiona cheltuielile urgente.

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

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

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

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

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

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

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