Глоссарий для QA часть 2
Zero Bug Policy Любой найденный дефект либо чинится немедленно, либо явно признаётся неважным и закрывается/откладывается с чётким обоснованием. Баг-трекер не свалка, а инструмент быстрых решений.
Bug Triage Регулярная сортировка входящих багов: приоритет, серьёзность, ответственный. QA фасилитирует или активно участвует, чтобы баги не гнили в статусе New.
Velocity Средний объём стори-поинтов, выполненных за спринт. Это инструмент прогнозирования, а не KPI продуктивности. QA прямо влияет на Velocity: незавершённые из-за дефектов истории снижают метрику и сигналят о проблемах.
Burndown Chart График оставшейся работы. Нездоровый паттерн — «обрыв» в конце спринта после плато, говорит, что команда тащила недоделанное. Для QA — триггер разобраться с узким горлышком.
Sprint Review Демонстрация готового инкремента стейкхолдерам. QA готовит тестовые данные и сценарии, чтобы показ не превратился в «ой, упало» на втором клике. Sprint Retrospective Встреча по улучшению процесса. QA выносит темы: почему тестирование затянулось, как стабилизировать тестовую среду, где взять время на автоматизацию.
Potentially Shippable Product Increment Инкремент, соответствующий DoD и пригодный для передачи пользователям. Ответственность QA — подтвердить это состояние, а не просто «потрогал и вроде работает».
Cross-functional Team Команда, у которой есть все компетенции для поставки ценности, включая тестирование. QA не отдельный департамент, а равноправный участник, разделяющий цели спринта.
Self-organizing Team Команда сама решает, как достигать цели. QA проактивно берёт задачи, влияет на архитектуру тестирования и не ждёт, что менеджер распишет план проверок.
Scrum Master Фасилитатор, коуч и разрулитель препятствий. Для QA Скрам-мастер — тот, кто поможет выбить тестовое окружение, договориться о времени на автотесты и подсветить проблемы качества на уровне команды.
· 10.06
Интересный концепт ! Похоже на работу на стороне вендора во внутреннем контуре продуктовой команды. Скорее всего этапа "Создание". QA Lead роль явно гибридная с элементами БА + ПМ.
Но есть и другие миры. 24/7 сопровождение follow-the-sun, SLA/CSM/Customer-faced team. И там как то все иначе.
Еще есть такие вредные люди - Деливери на фронте с заказчиком. Им не важно как ты оцениваешь баг внутри, если они выявили с заказчиком, что это SEV2 Urgent и SLA нарушается, то его вернут в Open и еще раз (много раз) напомнят и если нужно эскалируют. Баги из New в Open переведет SD без тестеров. Классифицирует, приложит логи/скрины/данные пользователя. Выделенный эксперт в смене оценит его Pri/Sev и лид разработки возьмет в спринт. Разраб все сделает и до тестера долетит в конце правок + сейчас CI/CD/AI все ускорили кратно. QA (MQA/AQA) проверит в DEV/TEST и сделает инструкции по откату и все запилят в PROD.
Команда конечно все решает !!! Но с одним НО - "в рамках SLA. где MTTR для Sev1 - часы, а Sev2 - дни (немного) и потом финансовые санкции".
Но ваш мир мне тоже нравиться ))
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 10.06
Бывает по разному) я чаще работал по Agile процессам, повезло, задачи не уходили в работу пока не были описаны так, чтобы было понятно всем, QA, DEV, аналитикам и продакту)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён