Comments 6
Так, в кратце-то - что вы сделали? Переложили написание части тестов на программистов?
Как решили вопрос с программистами, кто был против тестирования? Уволили/уволились?
Если коротко:
формализовали пирамиду тестирования
расширили зону ответственности за написания тестов у разработчиков, да разработчики стали писать больше тестов,
Убрали дублирование тестов на разных уровнях
Эта ситуация показала уровень зрелости команды, когда все члены команды поняли проблему, приняли её и совместно решили. Кадровых изменений в команде в связи с этими изменениями не было.
Интересная статья. Но вот интересно по табличке, где расписаны итерации и количество задач. Возможно я не правильно понял, но выглядит так, что с уменьшением задач готовых к тестированию, уменьшилось и количество "хвостов" по итогу. Плюс таска таске рознь, тесты могут занимать разное время.
Если под хвостами мы понимаем "старые" задачи (которые долго доходили до заказчика), то да количество хвостов сократилось. А так же сократилось общее время поставки, если в конце 24 года (в разных итерациях) 85% задач закрывалось менее чем за 30-40 рабочих дней, то в 25 году эта цифра упала до 15-20 рабочих дней.
С одной стороны соглашусь таска таске рознь. Но мы говорим о числах в районе 200 - 300 задач за полгода. Т.к. команда не меняла правила декомпозиции задач, исполнители те же. То можно считать, что на таком количестве неравность задач усредняется. Т.е. если были бы всплески коротких и длинных задач, то можно было бы говорить о необходимости кластеризации задач на классы обслуживания. Но тут такого не наблюдается.
Не понимаю, почему так много задач в тестировании и готово к тестированию? Почему так много времени уходит на тестирование этих задач?
Автоматизированное тестирование требует написания кода. А в начинающем продукте надо не просто составлять тест-кейсы из уже написанных шагов, но так писать новые шаги, формировать структуру тестового фреймворка. Что делает работу инженера по тестированию мало отличимой от работы инженера по разработке.
Не каждый инженер по тестированию выдерживал необходимый темп разработки тестов в нашей команде.
Как мы избавились от «бутылочного горлышка в тестировании» и увеличили пропускную способность команды вдвое