Путь к качеству: улучшение процессов разработки и тестирования

1.

Путь к качеству:
улучшение процессов
разработки и
тестирования
Компания: Альфа Алгоритм
Автор: Иван Костенюк

2.

Содержание
Контекст и цели
Интеграция QA
Подготовка задач
Коммуникации и
метрики
Выполнение и
проверка
Артефакты и
автоматизация

3.

Формат
План внедрения
Ожидаемые
результаты

4.

PART
01
Контекст и цели

5.

Текущее
состояние и
вызовы
Системные проблемы
Анализ регламентов и должностных инструкций выявил системные проблемы
на всех этапах от подготовки задач до релиза. Отсутствие единых стандартов
приводит к переделкам и снижению мотивации команд.
Цель изменений
Цель изменений — повысить качество продукта, эффективность команд и
снизить риски, сохраняя гибкость ScrumBan.
Основные подходы
Основные подходы включают внедрение стандартов DoR и DoD, интеграцию
QA на ранних этапах (Shift-Left) и усилении метрик ответственности.

6.

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

7.

PART
02
Подготовка задач

8.

Недостаточное
описание
Сырые требования
Разработчики берут
в
работу
требования
из-за
отсутствия
критериев готовности задач (DoR).
сырые
четких
Аналитики не заинтересованы в полном
описании, так как задачи принимаются без
проверки, а уточнения происходят позже,
тратя время команды.
Проблема: отсутствие
критериев готовности
Неопределенные понятия
Не определены понятия «полное ТЗ»,
«критерии приёмки» и «тестовые артефакты».
Нерегламентированный Wiki
Wiki как база знаний не регламентирована по ведению и
обновлению.

9.

Решение: внедрение DoR и grooming
01
02
Внедрение DoR
Изменение
процессов
Вводится обязательный чек-лист
Колонка «В очереди»
DoR перед взятием задачи в
превращается в
работу: четкое ТЗ без копипасты,
приоритизированный бэклог,
согласованные с QA критерии
обсуждаемый на еженедельных
приёмки, описание тестовых
grooming-сессиях. Wiki
данных, ролей и прав. QA
стандартизируется: назначается
подтверждает тестируемость.
ответственный за обновление и
интеграция с Confluence.

10.

PART
03
Выполнение и проверка

11.

Проблема: отсутствие критериев завершенности
Отсутствие критериев завершенности
(DoD) позволяет передавать задачи на
тест без базовых проверок.
Чек-лист не стандартизирован: неясны
источник и автор.
Отсутствие проверок
Нестандартизированный
чек-лист
Недостаточное
описание изменений
Расхождения кода с
требованиями
Разработчики не всегда описывают
изменения, полагаясь на добрую волю.
Это приводит к расхождениям кода с
требованиями и иллюзии качества
после локальных проверок, увеличивая
количество дефектов и возвратов.

12.

Решение: внедрение DoD и стандартов
Внедрение DoD
Обязательное
описание изменений
Стандартизация чеклиста
Вводится DoD: задача считается
Описание изменений становится
Создаётся единый шаблон чек-
завершённой
обязательным для всех задач.
листа
в
Kaiten
прохождения всех тестов (включая
Разработчик
команды
и
регресс),
реализацию на общем тестовом
только
после
обновления
документации (API в Swagger) и
слияния кода в основную ветку.
проверяет
стенде перед передачей на тест.
пересмотром.
с
авторством
регулярным

13.

PART
04
Интеграция QA

14.

Проблема: позднее подключение QA
Тестирование
«черного ящика»
Бесконтрольные
изменения
Недостаточный
анализ
QA подключается
поздно, тестируя
«черный ящик» без
участия
в
планировании.
Это превращает QA
в
регистратора
сюрпризов, а не
обеспечителя
качества.
Требования и код
меняются на этапе
тестирования без
управления
изменениями,
вызывая
бесконечный пингпонг.
Должностная
инструкция
тестировщика
фокусируется
на
исполнении,
игнорируя анализ
рисков
и
стратегическое
планирование.
Отсутствие прав
Нет
прав
на
блокировку
некачественных
задач.

15.

Решение: Shift-Left и расширение роли QA
Интеграция QA на
ранних этапах
QA интегрируется с момента создания задачи (Shift-Left): пишет тест-кейсы
параллельно разработке, консультирует по тестируемости. Вводится feature freeze
после grooming для фиксации требований.
Расширение роли QA
Должностная
инструкция
дополняется:
анализ
требований,
планирование
покрытия, участие в grooming и релизах, создание автотестов. QA получает право
блокировать задачи без DoR, требовать критерии приёмки и участвовать в решениях
о релизе. Переход к матричному подчинению QA (разработка + продукт/аналитика).

16.

PART
05
Коммуникации и метрики

17.

Поздние
уточнения
Нереалистичные
оценки
Уточнения у аналитиков происходят после
начала работы, создавая «испорченный
телефон».
Оценка сроков индивидуальна: 25% на тест
— фиктивная метрика, не учитывающая
сложность.
Проблема: размытая коммуникация и оценка
Отсутствие
процессов
Неприоритизированные
баги
Нет grooming, триажа багов, SLA на ответы
и единого инструмента для созвонов.
Баги не приоритизированы, по отношению
к другим задачам, нет пост-релизного
ретро. Это приводит к хаосу в приоритетах
и потере времени на бесконечные
уточнения.

18.

Решение: grooming,
SLA и ретроспективы
Внедрение
grooming
Реалистичные
оценки
Ретроспективы
Вводится еженедельный grooming
для
совместной
оценки,
обсуждения
рисков
и
формирования
критериев
приёмки.
Оценки
заменяются
реалистичными, учитывающими
регресс и тип задачи. Создаётся
матрица приоритетов для багов,
дежурство и SLA (ответ <2 часа на
критичные).
Переход на единый инструмент
(Slack/Discord)
для
быстрых
созвонов.
Проводятся
ретроспективы: отдельные QA и
кросс-командные после релиза
для анализа багов и улучшений.

19.

Накопление
незавершенных задач
Отсутствие WIP-лимитов приводит
к
накоплению
незавершённых
задач (Kanban без принципов).
Проблема:
отсутствие метрик
и WIP-лимитов
Некачественные KPI
KPI в должностных инструкциях
фокусируются на времени, а не
качестве. Нет метрик возвратов
задач, багов, покрытия.
Размытая
ответственность
QA как бутылочное
горлышко
Ответственность
размыта:
контроль
гендиректора
без
последствий за нарушения.
QA
становится
«бутылочным
горлышком» из-за накопленных
проблем, что снижает общую
эффективность команды.

20.

Решение: WIP-лимиты
и дашборд качества
Внедрение WIP-лимитов
Вводятся WIP-лимиты: не более N задач в «В
работе» и «Тестирование», стимулируя
взаимопомощь (разработчик помогает QA).
Дашборд метрик
Настраивается дашборд метрик:
покрытие 90%+,
баги до релиза 95%+,
стабильность
автотестов
<5%
ложных,
время на баги <2 часа, % возвратов
по причинам.
KPI фокусируются на качестве с
прозрачными
последствиями
за
нарушения: ретро для анализа, а не
наказания.
Kanban дополняется планированием
и ретро для предсказуемости.

21.

PART
06
Артефакты и автоматизация

22.

01
Неструктурированные
тест-кейсы
Тест-кейсы
хранятся
в
комментариях и чек-листах без
стандартов, smoke/регресс-сетов и
покрытия.
03
Нет требований к коду
Регламент
не
тестопригодного
разработчиков
локаторы).
требует
кода
от
(стабильные
02
Отсутствие интеграции
Нет интеграции ручных тестов с
автоматизацией:
пайплайн
на
Python существует, но без планов
роста.
04
Отсутствие
документации
Нет карты приложения, statemachine
процессов,
таблицы
ролей/интеграций для онбординга
и риск-анализа.
Проблема: хаос
в тестовых
артефактах

23.

Внедрение TMS
Внедряется TMS (Allure TestOps) для управления тест-кейсами, сетами и покрытием.
Стандартизация
артефактов
Создаются
стандарты
артефактов:
smoke/регресснаборы, интеграция ручных и
автоматизированных тестов.
Автоматизация
стандартизируется
на
Playwright TS с критериями
(стабильный функционал).
Решение:
TMS,
стандарты и
карта
проекта
Требования к коду
и документация
Разработчики
обязаны
предоставлять
стабильные
локаторы и обновлять тесты.
Создаётся карта проекта: вебприложение,
state-machine,
таблицы ролей/интеграций в
Confluence для онбординга и
анализа рисков.

24.

PART
07
План внедрения

25.

Пилот и
корректировки
Цель пилота
Пилотное внедрение
Рекомендуется
начать
внедрение с пилота на 1–2
спринтах с участием всей
команды.
Цель
пилота
—
проверить
работоспособность
предложенных
решений в реальных условиях, собрать
обратную связь и скорректировать
процессы.
Результаты пилота
В рамках пилота тестируются DoR, DoD,
grooming-сессии, WIP-лимиты и новые
метрики.
Результаты пилота фиксируются и
обсуждаются на ретроспективе для
принятия окончательных решений.

26.

Распространение опыта
Масштабирование
После
успешного
пилота
изменения
распространяются
на
все
команды.
Проводятся обучающие сессии по новым
стандартам и инструментам.
Поддержка и контроль
Создаётся чек-лист для самопроверки команд
на
соответствие
новым
процессам.
Назначаются «чемпионы» в каждой команде
для поддержки и контроля внедрения.
Регулярно проводятся встречи для обмена
опытом и решения возникающих вопросов.

27.

PART
08
Ожидаемые результаты

28.

Повышение качества и предсказуемости
Снижение дефектов
Стабильность
требований и кода
Предсказуемость
релизов
Внедрение DoR и DoD снизит
количество дефектов и возвратов
задач на 30–40%.
Четкие критерии готовности и
завершенности
обеспечат
стабильность требований и кода.
Предсказуемость
релизов
повысится за счёт реалистичных
оценок
и
фиксированных
требований
после
grooming.
Команды будут работать более
согласованно, а продукт —
отвечать
ожиданиям
пользователей.

29.

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

30.

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

31.

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

32.

Конец
Спасибо
Автор Иван Костенюк
Компания Альфа Алгоритм