Downtimes/Showstoppers. Как подготовить ответ на вопрос: "Почему не успели?"

Когда задают вопрос: "Почему так долго?"

Если вы когда либо планировали работу тестировщиков, то  наверняка  можете  вспомнить ситуации, в которых, вроде бы, все спланировано (протестировать 4 фичи, протестировать 2 бага, прогнать регрессию, прогнать тестирование производительности). Вроде бы заложено адекватное время (которое даже понравилось проект менеджеру). А на практике вместо положенной недели потратили 2 или даже месяц.

И вот предстоит ответить на вопрос менеджера "порхуя так долго".

И вы действительно не можете ответить точно. Вроде бы работали. Вроде бы даже тратили время на тестирование (именно на тестирование) как спланировали. Но действительно - куда делось время?

В заметке про планирование и отслеживание работы отдельно взятого проекта я уже упоминал про те риски которые можно учесть и минимизировать:
- ретестирование (у нас 30%, но у кого то может быть и больше),
- активности не связанные с тестированием (non-testig activities)
- простои в работе (downtimes).

Именно про downtimes я бы хотел сегодня вспомнить и посоветовать, как с ним поступить.

Тестирование - критичный процесс

Тестирование также как и разработка может быть критичным процессом в проекте. Почему тестирование может быть критичным процессом? Потому что всегда есть опции. Например тестирования, как процесса нет. Или тестирование можно пропускать, в случае сжатых сроков. Или мания  "святого кода" в команде разработки.

Если брать за основу, что именно мы являемся последним рубежом в definition of done (например, разработано-документация подготовлена-протестирована), то любой простой в работе грозит срывами сроков. Для команды это вдвойне обидно, так как будет считаться, что фичи/баги сделаны, а тестировщики "не успели".

В любом случае нужно быть готовым достойно ответить на вопросы (кто бы их не задал):

Сколько нужно потратить времени на тестирование?

Почему так долго?

Почему не успели?

Для тестировщиков я считаю важным знать и планировать простои в работе связанные с внешними причинами. Назову некоторые из них (критичные в моих отдельно взятых проектах):

- спецификация не поступила от пользователя, 

- разработка не была закончена или билд не был готов к тестированию,

- не готово тестовое окружение (программная ошибка, проблемы с аппаратурой).

Кстати, не забываем о всех проблемах и простоях сигнализировать флажками в отчете. Потому что у менеджеров есть еще несколько замечательных справедливых вопросов:

Когда произошла проблема? 
Сколько времени мы уже потеряли? 
Кому о проблеме сообщили? 
Как попытались решить? 
Предварительная оценка - когда проблема будет устранена? 
Как эта проблема влияет на даты окончания тестирования и выкатывания релиза?

Зоны ответственности тут явно могут быть далеки от зоны ответственности тестирования. Но этим и важна позиция тестировщика. Должны быть люди, которые заранее сообщают о проблемах и затем ведут за ней наблюдение, даже если эти люди не обеспечивают качество ;).

Downtimes vs Showstoppers

Про то как сигнализировать флажками я уже рассказывал, теперь поговорим о том, как регистрировать и копить статистику.

Все проблемы в проекте можно разделить на две категории - те которые могли повлиять на тестирование, и те, что действительно повлияли.

Например, один из региональных веб сервисов не доступен, но это вас пока никак не касается - вы можете продолжать тестировать другие региональные сервисы (благо их еще 3). Это проблема, которая могла бы повлиять на тестирование.

Если вы закончили тестировать другие регионы, а сервис все еще не доступен - эта проблема действительно влияет на тестирование.

Учитывать статистику советую для обоих категорий проблем.

Проблемы, которые на нас повлияли стремятся к среднему показателю, который можно использовать при планировании тестирования. В моем текущем проекте средний показатель 20% от затрат на тестирование.Средний показатель, конечно, это как средняя температура по больнице. Именно поэтому нужно еще учитывать и те проблемы, которые нас не коснулись.

Проблемы, которые случились, но не повлияли на вас - это потенциальные риски, которые могут сыграть в будущем. Порой они в несколько раз больше времени, которое мы тратим на тестирование. Чтобы минимизировать риски неплохо было бы провести Lesson Learned и показать их команде и менеджеру лично. Пусть тоже ночью не спят от кошмаров ;).

Как учитывать простои в работе

Учитывать простои в работе можно и в обычном табличном редакторе. Главное чтобы окончательный вчерашний суммарный результат был доступен всем. Можно добавить несколько строчек в ежедневный/еженедельный отчет.

Учитывать можно следующее:

Приложение + версия:

Дата начала проблемы:

Дата окончания проблемы:

Потеряно человеко-часов:

Владельцы проблемы:

Описание:

Потом можно даже построить табличку и подсчитать простои и всякие циферки (см. яркую картинку ниже).

А еще можно отдельно подсчитать сколько часов мы теряем из-за проблем:

- спецификация не поступила от пользователя, 

- разработка не была закончена или билд не был готов к тестированию,

- не готово тестовое окружение (программная ошибка, проблемы с аппаратурой).

И тогда у менеджера наверняка возникнут вопросы, но уже не к тестировщикам ;)