Комментарии 3
Привет, я имею неудовольствие работать сейчас с вашим детищем Shopper. Я думал что все плохо, но чтобы ты ОДИН там был из QA....
Могу такой вопрос задать - а какой приоритет у задачи "сделать так чтобы таймеры выполнения коррелировали с реальностью"?
Такое чувство что баги таймеров перевели в фичи по экономии денег на выплаты партнерам..
Привет! Расскажи, пожалуйста, а если задача в вашей команде оценена, например, в 5 или 8 sp, то вы не принимаете решение о ее декомпозиции ?
Просто я в команде действую таким же подходом, но у нас априори, если задача на автоматизацию больше 3х сп - ее сложнее трекать и ревьюить, соответственно есть смысл ее «грызть» более поэтапно, соответственно принимается решение ее декомпозить
Привет
Мы решили не дробить задачу, оцененную в 5-8 sp на подзадачи, чтобы не раздувать бэклог/спринт. Хотя данный подход с разделением на подзадачи тоже имеет место быть. Особенно, если задача действительно большая.
Приведу пример, чтобы более подробно аргументировать свою точку зрения.
Как правило, в 5-8 sp мы оцениваем задачу на автоматизацию тестирования, например, которая включает написание класса для сериализация/десериализации json, создание родительского класса для подготовки тестовых условий и написание самого теста. Кода может получаться действительно много для ревью, но у нас нет условия, чтобы ревьюер при проверке уложился в определенное время, поэтому мы объемные задачи стараемся делать сразу.
В 3 sp оцениваются обычно задачи по написанию небольших автотестов или изменению assertions.
Одинокий рейнджер, или как выстраивать тестирование, будучи единственным QA в команде