Тестирование IT-решений и обучение команды для корпоративной цифровой платформы

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

За 1,5 года команда участвовала в подготовке и проверке 66 релизов, выявила более 1000 дефектов и автоматизировала 91 тест-кейс. Параллельно мы помогли клиенту пересмотреть процессы тестирования, отчетности и взаимодействия между участниками разработки.

Бизнес-задача

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

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

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

В итоге сотрудничество охватило несколько направлений:

• функциональное и регрессионное тестирование интернет-магазина;
• подготовку тестовой документации;
• автоматизацию регрессионных проверок;
• контроль найденных дефектов;
• настройку процессов тестирования;
• обучение QA-команды клиента;
• подготовку отчетности о качестве;
• ИТ-консалтинг и аудит процессов корпоративной системы на базе 1С.

Проект постепенно вышел за рамки классического аутсорсинга тестирования. Команда «Точки качества» участвовала в развитии самой системы обеспечения качества у клиента.

С чего начали

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

В область тестирования вошли каталог и карточки товаров, главная страница, навигация, регистрация и авторизация, личный кабинет, корзина, оформление заказа и интеграция интернет-магазина с 1С.

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

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

Как организовали регрессионное тестирование

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

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

Команда сформировала набор приоритетных регрессионных проверок. На одном из этапов он включал 138 тест-кейсов, охватывающих ключевые функции интернет-магазина.

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

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

Зачем понадобилась автоматизация тестирования

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

Поэтому часть регулярных проверок мы перевели в автоматизированный контур.

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

Для работы применялись Selenium, NUnit, C#, Azure Pipelines, BrowserStack, Postman, WinAppDriver и другие инструменты.

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

Тестирование крупных изменений без остановки текущей разработки

Отдельной задачей стало тестирование масштабного обновления пользовательской части интернет-магазина.

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

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

Для разделения новой и действующей функциональности использовались A/B-тестирование (сравнение вариантов) и feature flags (флаги функций). Это позволяло управлять доступностью изменений и проверять новую функциональность, не включая ее сразу для всех пользователей.

Так команда могла тестировать крупные доработки и одновременно контролировать стабильность текущей версии сайта.

Как работали с дефектами и качеством релизов

За время проекта специалисты выявили более 1000 дефектов.

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

Поэтому тестирование сопровождалось подготовкой отчетов о качестве и контролем прохождения дефектов по рабочему процессу.

За 1,5 года команда приняла участие в проверке 66 релизов. Такой ритм требовал постоянной синхронизации тестирования с разработкой: QA должен был быть частью процесса выпуска изменений, а не отдельным этапом в самом конце.

Передача экспертизы внутренней QA-команде

Одна из особенностей проекта — работа с продуктом и с командой клиента.

Специалисты «Точки качества» передавали внутренним инженерам методологию тестирования и помогали выстроить ежедневные QA-процессы.

Вместе разбирали, как формулировать задачи, описывать найденные дефекты, готовить отчеты о качестве и организовывать работу с задачами и ошибками в Azure.

Отдельное внимание уделялось обучению новых инженеров по тестированию. Это было важно для масштабирования: процесс не должен зависеть от знаний нескольких конкретных специалистов.

В результате клиент получал практики, которые внутренняя команда могла использовать самостоятельно.

ИТ-консалтинг и аудит процессов на базе 1С

Интернет-магазин был связан с корпоративной системой на базе 1С, поэтому часть проблем нельзя было рассматривать только со стороны веб-приложения.

Эксперты «Точки качества» подключились к внутреннему аудиту процессов и ИТ-консалтингу.

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

По итогам анализа были определены зоны, требующие изменений, и предложены меры по организации работы между командами.

Три процессные задачи, которые пришлось решить

1. Показать бизнесу ценность тестирования. Одна из сложностей проекта была связана с восприятием QA внутри компании. Чтобы связать тестирование с задачами бизнеса, команда подготовила презентацию для руководства. В ней зафиксировали существующие проблемы проекта, их влияние и возможные пути достижения поставленных целей. Разговор о тестировании таким образом сместился от количества выполненных проверок к рискам и качеству выпускаемых изменений.
2. Наладить взаимодействие между участниками проекта. Для регулярного обсуждения проблем и точек роста были введены ретроспективы с командой разработки. На встречах разбирали сложности предыдущего периода, распределение задач и организационные проблемы. Это помогало устранять причины повторяющихся сбоев в процессе, а не только работать с их последствиями.
3. Сделать отчеты о качестве полезными для бизнеса. Технический отчет не работает, если его понимает только QA-команда. Поэтому специалисты пересмотрели формат отчетности и подготовили более понятное представление информации о качестве продукта. Новый формат оказался применим не только в рамках исходного проекта: впоследствии его начали использовать и другие команды компании.

Результаты проекта

За 1,5 года работы в проекте участвовала выделенная команда из 8 специалистов «Точки качества».

За это время:

• проверено и поддержано 66 релизов;
• выявлено более 1000 дефектов;
• автоматизирован 91 тест-кейс;
• подготовлены сотни тест-кейсов для регрессионного тестирования;
• выполнено более 9000 человеко-часов работ;
• внедрены практики автоматизации и регулярной регрессии;
• пересмотрен формат отчетности о качестве;
• организована передача QA-экспертизы внутренней команде;
• проведен аудит процессов корпоративной системы на базе 1С.

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

Что показывает этот проект

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

Поэтому масштабирование QA требует работы сразу на нескольких уровнях: тестирования продукта, автоматизации повторяемых проверок, организации процессов и передачи экспертизы внутренней команде.

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