2021-06-15 16:09:33
Открываем концерт по заявкам
Друзья, спасибо, что оставили свои идеи, какие темы вам было бы интересно поднять. В числе прочего пришло предложение разобрать реальный кейс.
Так чего же долго тянуть? Дано:
Scrum фреймворк. Позади несколько спринтов. Продукт пока не в продакшене.
Начали разработку без тестировщика.
Недавно тестировщик появился, и у клиента есть ожидание, что теперь с качеством все будет ок.
Пока что тестировщик проверяет функциональность прошлых спринтов. Новые по-прежнему закрываются без тестирования.
Вопрос: как можно нормализовать этот процесс?
Здесь много вариантов решений, которые с разной степенью эффективности могли бы выровнять ситуацию.
Я опишу, через какие ключевые фазы я бы прошла, если бы решала вопрос значительного отставания тестирования от разработки у себя на проекте.
Определить статус-кво по качеству и запаздывание тестирования. Это актуализация проблемы для команд и клиента.
У нас серьезный беклог задач для тестировщика, накопленный за прошлые спринты. В параллель идет разработка нового функционала. Можно примерно прикинуть, когда сойдутся кривые разработки и тестирования на графике.
Показать, что с текущей производительностью тестировщик догонит разработку в условно 15м спринте (если вообще догонит).
А до этого времени продукт будет ниже ожидаемого уровня качества и отдавать его на продакшен рискованно.
Если расчеты показали, что к ожидаемой дате релиза ситуация сама не выровняется, переходим к п.2
Обсудить с командой возможные варианты решения проблемы.
Можно в режиме брейншторма набросать идеи, как нагнать отставание по тестированию.
Например:
Подключить дополнительного тестировщика на Х недель.
Выбрать задачи, которые можно покрыть отличным от мануального тестированием и отдать их разработчикам.
Остановить девелопмент новых фичей, временно приоритезировать задачи по приобретению знаний, устранению тех долга (если уже успели за несколько спринтов оставить должок).
Оптимизировать тест стратегию и подходы, уменьшить глубину тестирования.
Возможно, не нужно сейчас тщательно тестировать все готовые фичи. Достаточно будет протестировать happy path для критичного базового функционала? Можно использовать упрощенную тест документацию.
Можно обсудить с клиентом ожидания по качеству и попробовать снизить их, если это совпадает с бизнес целями.
Заменить разработчика на тестировщика на Y недель, чтоб выровнять баланс – чуть меньше девелопить и в два раза больше тестировать.
Разделить окружения для разработки и тестирования, чтобы тестировщик работал изолированно только с версией, которая планируется к релизу, исключить попадание в эту версию сырых фичей.
Прикинуть стоимость и реалистичность этих вариантов решения с учетом: известных приоритетов и ограничений клиента,
доступности ресурсов.
Подготовиться к обсуждению ситуации с клиентом.
Я бы сделала презентацию с визуализациями, плюсами и минусами разных вариантов решений. Постаралась бы подвести клиента к выбору оптимального варианта.
Зафиксировать договоренности и реализовать их. Расставить контрольные точки и метрики, которые позволят нам понять, что план по устранению отставания по тестированию работает, как мы того ждали.
Надеюсь, в этом лонгриде автор вопроса найдет подсказки для нормализации ситуации на проекте.
235 views13:09
К
