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

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

Как выбирали TMS и почему выбрали Test IT

Мы перебрали почти всё, что есть на рынке РФ. Основными критериями были: цена, удобство для ручного тестирования, красивые и понятные отчёты, интеграции с автотестами и поддержка. Сравнительная табличка ниже. Несмотря на то, что Test IT  в нашей выборке был одним из самых дорогих решений, он бесспорно выиграл по удобству, качеству отчетов, наличию дашбордов и возможности объединять результаты ручных и автоматизированных тестов. Дополнительным жирным плюсом оказалась, внезапно, их команда продаж. Я довольно долго мучал ребят своими вопросами, а они стоически мне помогали и по настройке дашбордов, и по пробрасыванию автотестов в TMS, и по управлению лицензиями, и в целом по адаптации системы под наши нужды.

Сравнение TMS

Как мы внедрением занимались

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

С выбором всё было относительно просто — собрали таблицу сравнения, взвесили плюсы и минусы, приняли решение. А вот внедрение оказалось куда более многоуровневым процессом. До этого TMS в компании не использовалась, и для многих коллег сам подход был новым — не все понимали, зачем нужна система управления тестированием и как с ней работать.

Мы начали с подготовки: провели внутренний воркшоп с Q&A‑сессией для всех сотрудников, где объяснили не только сам инструмент Test IT, но и базовый подход к построению тестовой модели. В дополнение к воркшопу подготовили пошаговую инструкцию, как работать с системой и как интегрировать её в повседневные процессы.

Сразу после — выдали лицензии всей QA‑команде, чтобы можно было на практике изучить инструмент. Новые проекты начали вести сразу в Test IT, старые — переносили из Google Docs. Чтобы облегчить миграцию, мы сделали шаблон чеклиста в Google Таблицах, адаптированный под формат Test IT. QA нужно было лишь привести свои существующие проверки к этому шаблону, после чего загрузить их в систему и доработать при необходимости.

Импорт/экспорт тестов между системами — тема всегда непростая, но в нашем случае всё прошло достаточно гладко: большинство проверок изначально велись в Google Таблицах в виде чеклистов, и у нас не было громоздких структур или кастомных полей, которые требовалось бы переносить.

Что у нас есть уже сейчас

• Каждый проект разработки живет в своем проекте в TMS. У проектов есть как сама тестовая модель, так и настроенные дашборды, по которым мы отслеживаем обогащение проекта тестами и их прогоны. 

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

• Перед демо выгружаем проверенные кейсы, делаем отчёт заказчику

Какую ценность приносит TMS нашим заказчикам

1. Радикально повышается прозрачность работы QA: наши клиенты видят, как мы проверяем продукт.

2. Мы можем показать реальный объем работ по тестированию, а не просто «мы полдня тестировали перед релизом, нашли баги, зафиксили».

3. Клиент становится активным участником процесса разработки и понимает, что именно было протестировано и зачем.

4. У клиента появляется удобный рычаг управления качеством и понимание, за что он платит. Становятся понятны для всех сторон ситуации, когда надо увеличить объем тестирования, а где появляется относительно безопасная возможность им немного пожертвовать в угоду скорости.

Как мы планируем масштабировать это дальше

Test IT у нас уже активно используется более чем на 15 проектах. Следующие наши шаги направлены на дальнейшее развитие культуры обеспечения качества:

• Включение отчетов по тестированию и дашбордов проектов в релизные демонстрации на Demo.

• Интеграция автотестов с TMS, чтобы всё было в одном месте и можно было сокращать время на ручное тестирование с учетом регулярных запусков автотестов.

• Продолжаем прокачивать TMS как интерфейс QA‑команды: и для менеджеров, и для заказчиков, и для команды разработки.