Публикация Школы траблшутеров

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

Время чтения: 11 мин 20 сек
20 декабря 2023 г. Просмотров: 245

Тестирование, Разработка | Олег Брагинский, Владислав Бурлака

Ставки на спорт – доходный бизнес, привлекающий азартных да ушлых. Ошибки программного обеспечения способны мгновенно привести организаторов к краху. Основатель «Школы траблшутеров» Олег Брагинский и ученик Владислав Бурлака рассказывают, как уберечься.

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

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

  • корректность работы страниц приложения на стороне пользователя: ставки в реальном времени, онлайн-развлечения, информация о продукте, профиль пользователя, корзина
  • задержка обработки операций до 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.

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

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