>= времени,потраченного DEV командой на разработку фичи. И не совсем понятно, где идет просадка и в чем может быть причина.
Кто-нибудь сталкивался с подобным?
( 127% QA против 100% DEV).
я сталкиваюсь с подобным в своей работе. Причина почти всегда - в размытой логике новых задач, поиск глубины контекста, и формировании из "узкой" спецификации ее края соприкосновения с общей системой. Как это делать быстрее? Узнать продукт, написать тестовую документацию, договориться о формальных с лидом терминах о событиях, которые будут приближены к тестовой задаче, а не девелоперской
А какой результат у фичи - количество пройденных тестов к количеству тестов на фичу?
Время на тестирование зачастую превышает время разработки в 1,5-2 раза
На одной из прошлых работ было. Решалось путем внедрения CI и тестов. Цепочка выглядила так: Проверка кода на кодконвекшн (внутренняя разработка программеров) -> юнит тесты -> апи тесты -> автотесты для UI -> ручное тестирование.
А почему вообще мы смеем утверждать, что "просадка" была?
А кроме того, что QA потратило больше времени чем DEV, есть проблемы?
Обсуждают сегодня