Как мы внедряли систему управления тестированием

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

Мы Apibank, международная IT-компания, работающая в новом растущем сегменте Open Banking. Apibank создает собственные платформенные продукты и решения, как для конечного потребителя SaaS, так для партнера BPaaS.

Apibank позволяет бизнесу встраивать финансовые продукты в свои приложения через удобные API по принципу Bank-as-a-service, тем самым улучшать пользовательскии опыт, повышать LTV и маржинальность своего бизнеса, создавать новые бизнес-модели.

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

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

Как выбирали

На первом этапе опросили коллег, кто чем пользуется, и провели небольшой деск-рисерч. Так у нас появились пять претендентов: TestLink, TestRail, Qase и Test IT. Затем мы сравнили эти решения.

Как мы внедряли систему управления тестированием

В итоге мы остановились на российском Test IT.

Приятными дополнениями к нашим основным пожеланиям к продукту стали:

  • интуитивно понятный интерфейс;
  • простота создания кейсов и тестовых прогонов. Не нужно было тратить много времени на обучение работе в системе;
  • возможность формировать отчеты по результатам тестовых прогонов;
  • Двусторонняя интеграция с Jira.

Как внедряли

Чтобы новая система заработала, нужно не только установить ПО, но и поменять/настроить процессы. Этим мы и занялись вместе ребятами из Test IT.

Для каждого проекта Apibank было создано свое рабочее пространство. Затем мы занялись написанием кейсов для smoke-тестирования.

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

Как мы внедряли систему управления тестированием

Для нас было важно, чтобы при заведении кейсов их описания были максимально понятны. Чтобы любой тестировщик из другого проекта мог зайти и разобраться, как быстро провести тестирование. Только так можно гарантировать высокое качество продуктов вне зависимости от того, кто из специалистов ушел в отпуск или на больничный. И с этим система Test IT справилась отлично.

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

Как мы внедряли систему управления тестированием

Сейчас все кейсы, необходимые для smoke-тестирования, уже созданы, и мы завершаем добавление кейсов для прохождения регресса. Также была проделана большая работа над пополнением библиотеки кейсов и ее поддержкой.

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

Спасибо всем, кто помогает делать продукты Apibank лучшими!

22
2 комментария

я если честно, не уловил профитов с этой программы, вы несколько раз упоминаете smoke-test, но вообще-то это неотъемлемая часть работы программиста, который закрывает задачу
Дымовой тест — в тестировании программного обеспечения означает минимальный набор тестов на явные ошибки. Дымовой тест обычно выполняется программистом

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

Ответить

Добрый день.
Smoke-тест у нас составляется QA в сотрудничестве с менеджерами проекта.
Дымовой тест не всегда выполняется программистом, а ссылаясь на свой опыт скажу что не встречала в реальности, чтобы его проводили программисты. Обычно всю ответственность делегируют именно отделу QA. Но я не отрицаю, что где-то это ответственность разработчика.
Сейчас в компании идет активное покрытие юнит тестами и функциональными тестами, пока это на этапе разработки.

Ответить