Как мы строили департамент тестирования беттинговой платформы?

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

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

• корректность работы страниц приложения на стороне пользователя: ставки в реальном времени, онлайн-развлечения, информация о продукте, профиль пользователя, корзина
• задержка обработки операций до 0,5 секунды под средней – 2’000 пользователей в секунду и пиковой нагрузками – 5’000 одномоментных потребителей
• независимая работоспособность микросервисной архитектуры на стороне обработки транзакций.

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

Собрали бэклог в Jira, добавили описания эпикам, сторис, таскам. Установили, что 35% задуманного продукта уже готово, но не протестировано, а 65% бэклога планируется завершить в оговорённый период. Это соответствовало 18 эпикам и 360 историям.

Оценили предполагаемую работу в 2’160 часов: в среднем по шесть часов работы на апробацию сторис. Не забыли учесть и другие загрузки по разработанному функционалу, который установили, как 195 историй, требующих 1’170 часов тестирования.

Дополнили калькуляцию иными этапами работ:

• настройка и отладка исходной версии продукта на различных окружениях: dev, stage, prod
• подготовка инструментария для тестирования безопасности и производительности
• создание CI/CD процедуры, встроенной в общий процесс разработки
• внедрение методологии Agile Scrum с двухнедельными спринтами
• написание автоматизированного тестового фреймворка
• подготовка базовой и итеративной документации
• развёртывание тестового окружения
• проведение регулярных церемоний
• создание системы отчётности.

Заложили Bus factor – пропадание экспертизы при внезапном уходе ключевых членов команды в размере 20% дополнительного времени на отпуска, больничные, онбординг и оффбординг.

Дополнительных активностей набежало на 1’100 часов, что в сумме дало 4’430 слотов времени, за которые департамент тестирования должен был обеспечить качество конечного продукта.

Рассчитали нагрузку инженера за период:

5 месяцев х 21 рабочий день х 6 часов = 630 человеко-часов.

Значит, чтобы покрыть обозначенное количество усилий, потребуется создать команду из:

4’430 часов / 630 человеко-часов = 7 человек.

Перед запуском процедуры найма провалидировали фронт регулярных работ:

1. Проведение активностей и коммуникация в рамках существующей методологии разработки.
2. Ручное и автоматизированное санитарное, смоук и регрессионное тестирование.
3. Создание новой и доработка существующей документации.
4. Работы по оценке безопасности и производительности.
5. Мониторинг и отчётность.

 Определили конечную потребность проекта в составе:

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

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

Цикл найма разбили на этапы:

1. Согласование бюджета с целью реализации поставленных задач конкретного проекта.
2. Составление требований и определение зон ответственности будущих кандидатов.
3. Выкладка вакансий на поисковых ресурсах: LinkedIn, Indeed, и локальных сайтах.
4. Сбор, обработка и валидация полученных резюме на предмет их соответствия.
5. Определение процедуры прохождения интервью в рамках иерархии компании.
6. Анализ и отбор подходящих ожидаемой позиции в компании соискателей.
7. Проведение пятиэтапного интервью комплексного отбора с кандидатами.
8. Сбор и анализ полученной обратной связи, принятие решения о найме.
9. Подготовка и проведение трёхступенчатой онбординг-процедуры.
10. Определение ожиданий на испытательный срок.
11. Планирование будущего плана развития (PDP).
12. Внедрение и адаптация новичков.

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

Параллельно готовили базовую документацию:

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

Определили и задействовали инструментарий:

• TestRail. Подготовили инструмент для сбора и обработки тестовых случаев, наборов, сценариев и отчётности. Иерархично разбили на этапы, циклы, тест-планы и тест-наборы.
• Java + Selenium + RestAssured. Выстроили автоматизированный фреймворк на Java, покрыв максимально возможное количество случаев на front и back-end частях веб-приложения.
• Grafana K6. Внедрили общедоступный инструмент для тестирования производительности и нагрузки, покрыв основные бизнес-сценарии, встроив в общий цикл.
• CharlesProxy. Проанализировали трафик через кросс-платформенный HTTP-отладчик, проинспектировав SSL & TLS трафик и доменную категоризацию.
• Oracle SQL Server. Для периодического тестирования данных вынуждены были погружаться в базу данных с помощью автоматизированных SQL-инъекций.
• Allure. Необходимость встраивания автоматических отчётов на основе пройдённых автотестов также вписалось в общий концепт. Компактная веб-форма позволила быстро определять и устранять возникающие проблемы.
• JIRA. Для управления целевым продуктовым и спринт бэклогом после описания и распределения группы и типы задач в команде.
• CircleCI. Встроили подходы статического (SAST) и динамического (DAST) тестирования уязвимостей в общий CI/CD. В первом случае использовали SQL-инъекции и XXE (XML external entity) атаки с помощью Checkmarx. Во втором – сканирование уязвимостей в режиме реального времени, используя Arachni.
• NetSparker. Для оценки безопасности в каждое тестовое окружение встроили решение в рамках общего цикла разработки, что позволило автоматизировать определение уязвимостей на каждом этапе разработки.
• Confluence. Внесли документацию по проекту с особенностями проведения активностей по тестированию, онбординг и оффбординг процедур, сэкономив львиную долю временного ресурса на внутрикомандные встречи.
• Chrome DevTools & Fiddler. Проинспектировали входящий и исходящий поток данных в рамках используемого браузера, сравнив результат между двумя схожими инструментами для большей объективности.

Воспользовались техниками тест-дизайна:

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

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

В рамках церемоний скрама тремя базовыми ролями владельца продукта, Scrum-мастера и команды прояснили роль и функции тестирования:

• Sprint Planning. Определение и оценка предстоящих работ, сложность и полнота описания, проработка деталей внедрения и проверки. Длительность от одного до двух часов.
• Sprint Retrospective. Обзор успешных практик, подходов, процессов, что пошло не так и что стоит улучшать в последующих итерациях. От одного до трёх часов.
• Backlog Refinement. Валидация предстоящих задач на спринт и оценка приоритетности, релевантности и готовности. Час в неделю, дважды за итерацию.
• Daily Scrum. Валидация проделанной и предстоящей работы в рамках приоритетных задач рабочего дня: сделал, планирует, есть ли блокеры. Ежедневно по 15 минут.
• Sprint Review. Демонстрация проделанной работы в рамках цикла для представителя заказчика. От одного до четырёх часов.

Не забыли о регулярных 1-на-1 сессиях с тестировщиками для сбора обратной связи и оценке 360° для объективизации текущего положения продуктивности каждого инженера в отдельности.

Столкнулись со сложностями:

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

Внесли доработки и улучшения:

1. Повысили стабильность команды, улучшив процесс отбора кандидатов, процедуру регулярной обратной связи, программу развития навыков в зависимости от специализации.
2. Предложили внутренний КРІ без задействования дополнительного бюджета на создание и поддержание актуальной библиотеки знаний.
3. Изменили подход к описанию требований путём сокращения описания и внедрения специализированной терминологии.
4. Утвердили перечень и календарь встреч в рамках спринта, удалив несущественные и неэффективные.
5. Внедрили валидацию требований и приоритетов заказчика на ранних этапах с фиксацией бэклога.

Оценили результат:

1. Выпустили рабочую версию продукта с нулём критических и важных багов.
2. Заложили крепкий фундамент экспертизы и культуры тестирования.
3. Получили двух клиентов на выставке в Лондоне с двухлетним контрактом, покрыв 57% годовых расходов компании.
4. Поставили на поток процесс разработки и доставки 60+ фич за итерацию с 5-% важных дефектов на продакшене.
5. Выполнили запланированный объём работ за 4 месяца и 23 дня в рамках 611 сторис от изначальных 555.

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

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