Презентация тест плана в начале каждой итерации

Давно используем одну интересную практику в наших проектах – на следующий день после планирования очередной итерации тестировщик презентует всей команде тест-план на данную итерацию.

Презентация проходит следующим образом. У тестеровщика в TestLink на каждую итерацию (версию) имеется свой набор тестовых сценариев. При этом каждая история из бэклога (если это SCRUM-команда) или каждый вариант использования из спецификации должен быть покрыт тестовым сценарием. Тестировщик рассказывает команде, как именно он собирается тестировать тот или иной вариант использования, перебирая по очереди все тестовые сценарии. При этом у команды возникает масса пожеланий на расширение тестовых сценариев, оговорок, а так же уточнений по функционалу. По результатам такого ревью тестировщик обновляет тестовые сценарии, а аналитик, если требуется, корректирует спецификацию.

Данная практика способствует тому, что вся команда (и product owner, если он присутствует) одинаково понимает, что именно будет сделано и в чём суть каждой задачи. Так же снижаются риски связанные с поздним тестированием.

Метрики – качество оценки

Одна из полезных метрик, которую мы собираем на проектах, которые идут у нас по SCRUM – это подсчёт отношения запланированного на реализацию задачи времени к реально потраченному на них времени.

На ретроспективе, при рассмотрении того, что как шло в спринте, мы обращаем особенное внимание на задачи, у которых это отношение равно или превышает 1,5 или меньше или равно 0,6. Понимая, почему на реализацию той или иной задачи у нас ушло гораздо больше/меньше времени, чем планировалось, мы придумываем что-то, что в будущем делает наши оценки подобных задач более точными или уменьшает неопределённость на ранней стадии работ над задачей, что позволяет сделать переоценку как можно быстрее.

Пример такие действий: выделение отдельной задачи на интеграционное тестирование или включение в историю задачи по предварительному исследованию предметной области.