Тег #QA сбросить

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

Роли в продуктовой команде

Продукт/Product Owner — создаёт новые идеи для продукта, чтобы решать проблемы пользователя или увеличить прибыль продукта/компании.

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

Руководитель проекта/Delivery manager/IT Project manager — организует процессы работы в команде, отвечает за сроки и порядок выполнения фич, контролирует доставку фич до прода (пользователя). Работает и транслирует команде принятую методологию. Выполняет функции *Scrum-master*'а, но влияет на команду, работает с ней, а не просто «фасилитирует и передвигает карточки».

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

Аналитик/System analyst — раскладывает бизнес-требования на текущее поведение системы, систематизирует и структурирует требования. Проектирует решение.

Очень важно: чтобы проектирование решения было не в отрыве от команды. Решение всегда лучше проектируется всей командой, потому что один человек не может удержать все нюансы продукта в голове.

Дизайнер/UI|UX designer — отвечает за визуальное отображение и удобство функционала для пользователя. Работает с прототипами, собирает фидбэк от пользователя и думает над улучшениями.

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

Бекендер/Backender — отвечает за основную логику продукта, за его бизнес-поведение, скорость работы и отказоустойчивость.

Очень важно: должен хорошо понимать и системный уровень продукта, а также разбираться в бизнес-слое. Не делать необдуманных решений, при подборе решения под задачу лучше сделать 1–2 прототипа и сравнить, чем впоследствии понимать, что выбранное решение было ошибочным. Проводить ревью аналитики.

Фронтендер/Frontender — отвечает за реализацию UI. «Переносит макеты в код :)». Созданные компоненты должны быть легко переиспользованы. Создаёт логику работы с бэкендом.

Очень важно: ревью дизайна через призму наличия компонентов в дизайн-системе и создания новых. Упрощать фантазию дизайна в зависимости от сроков задачи, не давать плодить компоненты-«одиночки». Диктует бэкенду контракты взаимодействия.

Тестировщик/QA — отвечает за качество в продуктовой команде, а это значит отвечает и влияет почти на всё. Ревью идей на оценке, ревью требований аналитики, ревью дизайнов. Ревью тест-кейсов (если у вас больше одного тестировщика). Разбирает проблемы с прода, воспроизводит их, что помогает быстрее разработке найти источник проблемы.

Очень важно: QA всегда должен быть заточен на то, что он является двигателем команды к качеству. Да, хк, хк и продакшен бывает часто, но указать, что нужно запланировать рефакторинг тех или иных моментов. Завести баги, с которыми можно выйти в прод, но не забыть, что их нужно исправить. Ревью всего в команде делает QA отличным источником знаний, особенно в случаях: «Как это работает, судя по коду не должно вообще работать».

В этом году я решил попробовать нестандартные методы для обучения: интенсивы, игры и другие подходы.

Вашему вниманию представлена деловая ролевая игра «Оценка задач», которая готовит проджект-менеджеров ко всем возможным ситуациям в процессе оценки. Рефлексия после каждого «раунда» помогает закрепить материал.

Концепция игры

Что такое «оценка» — это процесс демонстрации продуктом идеи для команды с подготовленными артефактами: прототип и описание того, как идея решает проблему пользователя.

Для кого: для команд разработки и проджектов.

Роли участников: - РО — продукт-оунер, рассказывает идею команде, отвечает на вопросы, хочет получить объективную оценку. - ПМ — руководитель проекта, руководит процессом оценки. - Аналитик — проводит поверхностный анализ задачи и варианты наложения на текущую архитектуру системы. - Дизайнер — отвечает за визуальную реализацию, должен обращать внимание на прототипы, важно обсуждать с фронтендером возможные решения. - Бэкендер — проектирует решение, должен полностью понять, что хочет продукт. - Фронтендер — проектирует реализацию UI, должен ограничивать полёт фантазии дизайнера. - Тестировщик — оценивает объём тестирования, возможные риски решения и подводные камни.

Концепция игры: 1. Создание ситуации оценки задач продукта. 2. Участники должны быть в неестественных ролях, например, разработчик получает роль аналитика или тестировщика. 3. У каждой роли есть антипаттерны поведения, которые участник разыгрывает в ситуации. 4. Задача участника с ролью руководителя проекта — преодолеть все антипаттерны поведения, выдержать встречу в рамках и добиться результата.

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

Процесс проведения

Начинается сама игра: 1. Ведущий рассказывает правила: 3 оценки, каждый будет в роли ПМа и в роли одного из участников оценки: аналитика, разработчика, тестировщика. 2. Назначается первый ПМ, раздаются роли индивидуально остальным. Даются пояснения. 3. Когда все готовы — объявляется старт первого раунда. Засекается таймер на 15 минут. 4. Руководитель QA, он же играет роль Product Owner, запускает демонстрацию экрана с первой продуктовой задачей. 5. Модерация встречи полностью переходит к играющему ПМу. 6. Оценка проходит согласно нашему процессу разработки. 7. Оценка заканчивается. Объявляется стоп-игра. 8. Проджект-менеджер пытается угадать, с кем он только что оценивал задачи. 9. Дальше рефлексия всех участников первой итерации. 10. Повторяется для ещё 2 сценариев. 11. В конце рефлексия по всей игре: начинает приглашённый на роль Product Owner, дальше остальные участники. В конце ведущий проговаривает важные нюансы и основные ошибки, которые были допущены. Обсуждается, как их в дальнейшем не допускать и исправлять.

Как прошла игра

Игра была проведена между всеми проджект-менеджерами нашей компании, всего их трое. Был приглашён руководитель тестирования на роль Product Owner. Я был ведущим, но при этом отыгрывал одну из ролей из списка, следил за выполнением условий игры и подмечал моменты, которые нужно было вынести на обсуждение.

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

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

Выводы после игры

1. Всем понравилось.

2. Каждый испытал на себе разные роли, что позволило подойти к заданию творчески.

3. Прошло нескучно.

4. Много кейсов было решено правильно.

5. Во время рефлексии многие вспомнили похожие ситуации, а также проанализировали во время игры, что не получилось.

6. Были подсвечены проблемные места и что нельзя ПМам делать на такой встрече.

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

Начальный этап

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

Переход к автоматизации

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

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

Интеграция в процессы разработки

Следующим этапом стала интеграция тестирования в цикл разработки (CI/CD). Тестировщики начали работать в тесном взаимодействии с разработчиками с ранних стадий проекта, что способствовало: - Раннему выявлению дефектов. - Сокращению времени на исправление ошибок. - Формированию культуры качества во всей команде.

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

Современные тенденции

В настоящее время тестирование в Kaspersky эволюционирует в сторону использования искусственного интеллекта и машинного обучения для: - Предсказания потенциальных проблем. - Оптимизации тестовых сценариев. - Анализа больших объёмов данных о качестве.

Такие инновации позволяют командам адаптироваться к быстро меняющемуся рынку и повышать эффективность процессов.

Значение для продуктов

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

Подробнее об этом можно узнать в видео: https://youtu.be/j5u_sv_Uzrk