Планирование и отслеживание тестирования для отдельно взятого небольшого проекта

Введение

Разные проекты имеют разные подходы, технологии и методы в оценке трудоемкости и планировании. В данной заметке я предложу подход, который выработался в ходе развития одного проекта.  Не случайно в заголовок добавлено "отдельно взятого" - любой проект имеет свою историю, свою методологию, свой опыт и свои ошибки. Каждый проект планирует по своему. Это не хорошо и не плохо - так есть. Другое дело, что некоторые советы могут быть полезны в других отдельных проектах, которые отличаются и количеством и качеством. И — некоторые советы могут быть вредны в других отдельных проектах, которые несколько похожи.

В заметке я опишу характеристики проекта и процесс разработки, чтобы определить похожие или отличные вещи, опишу как мы планируем и предложу шаблон для планирования-отслеживания работ. Также в конце я привел несколько жизненых кейсов, которые решаются описанным методом с использованием шаблона, и сделать вы это можете менее чем за полчаса.

Характеристики отдельно взятого проекта

Проект, результаты которого я описываю ниже, достиг того уровня зрелости, когда и разработчики и тестировщики могут оценить свою работу и с известной долей вероятности указать дату окончания разработки\тестирования. Для меня, как для самого "старого" тестировщика проекта было важно определить дату и вероятность того, что тестировщики на определенную дату успевают закончить и функциональное и регрессионное тестирование, а также заложить время для ретестирования багов, обнаруженных в процессе проверки релиза.

Упомяну основные черты проекта, в которых  сформировался метод  планирования и отслеживания работ:

1. Команда небольшая - 3 разработчика, 4 тестировщика. Очевидно, описываемый далее  подход можно применить и к команде 5 разработчиков 6 тестировщиков или что-то вроде того. Для команд больших (10*10 например), указанные методы могут быть полезны, а могут быть и  узким местом.

2. Релизы частые (каждые 1,5 - 2 месяца, в среднем - 7 релизов в год) и поэтому важна дата с малой погрешностью (+/- 2 дня), когда мы (тестировщики) можем закончить работу, поскольку спустя две недели от этой даты должен быть релиз. Две недели - это срок, за который возможно пройти всю бюрократию, связанную с утверждением релиза (компания большая, следовательно бюрократия имеет обыкновение затягивать любой процесс).

3. Тестировщики планируют работу исходя из данных, которые дают разработчики и PM, как-то: какие фичи будут реализованы, какие баги будут исправлены, когда разработчики собираются закончить работу.

4. Проект имеет частые (1-2 в неделю) новых билда доступных для тестирования, каждый содержит новую фичу или починенный баг (или набор фичей багов). Довольно часто данное правило нарушается и разработчики делают дополнительный релиз, чтобы тестировщики не простаивали. Тестировщики проверяют фичи/баги и в случае найденной новой ошибки "возвращают" изменение в разработку. И опять новый билд, новый виток тестирования - бывает так, что баг ретестируется на той же самой неделе, что и был найден.

5. Регрессия начинается, только когда закончится функциональное тестирование. Иногда можно начать регрессию для некоторого функционала раньше, чем закончиться тестирование другого функционала – если разработчики клянуться, что точно ничего не будет задето ))). На самом деле накоплен опыт, когда мы действительно знаем, что затронуто изменениями будет только определенный функционал.

6. Нужен ежедневный отчет (у нас он называется Status Daily Report) о прогрессе тестирования. И тем более важно количество часов, которые мы потеряли и потратили ежедневно. Дата окончания тестирования может "плавать" на те самые +\- 2 дня.

7. Проект связан с другими проектами данными. Это выражается тем, что данные  передаются через сервисы в аппликации, причем и сервисы и аппликации - другие проекты, к которым мы имеем отношение только на уровне компании. Т.е. есть наш проект и несколько других. Между нами есть промежуточные приложения. Картинка связей всех приложений в рабочем процессе не умещается на экране, а если умещается, то названия аппликаций прочитать невозможно. Если ломается тестовое окружение в одном из внешних приложений мы должны тестировать что-то другое. Если нет других областей для тестирования - мы стоим. Это наши environment downtimes.

8. Что немаловажно – проект изначально начинался в Лондоне, переносился в Сидней и поддерживался индусами. В 2009 году он осел в Москве. По коду можно проследить, как разработчики изучали паттерны проектирования (то только синглтоны, то только фабрики), встретить код не только на Java, но также на Perl, C. Можно сказать студенты половины земного шара приложили к написанию кода и тестированию свои руки и желание изучать (=внедрять) все новое, что они прочитали.

Это вкратце о проекте.

Как мы планируем

Kick off meeting

Как правило, мы знаем, что будет нами тестироваться. У нас есть специальный пунктик - перед выдачей в тестирование проводиться митинг (или серия митингов) между тестировщиками, разработчиками и PM. Результатами переговоров являются:

- даты окончания разработки (для разработчиков),

- даты окончания функционального и регрессионного тестирования,

- даты в которые тестировщики могут уложиться и даты критичные для релиза.

- окончательно утрясенный (процентов на 80%) набор фич или багов,

- решены вопросы с ресурсами (кто в отпусках, кто на тренингах),

- определены риски (этот пунктик новый и не всегда выполняется, но постепенно управление рисками тестирования становиться обязательной процедурой)

Как мы оцениваем

Функциональное тестирование оценивается по факту. Мы накопили достаточный опыт, чтобы построить карту/roadmap для каждой фичи-баги - т.е. те крупноблочные действия/шаги которые мы должны сделать (без всяких там "гламурных" ожидаемых результатов) - сухие  единицы работы. Примерно на каждый шаг нам нужно 5 минут (шаг создать и проверить = 5 минут, шаг изменить и проверить = 5 минут, ... ). цифре мы прибавляем 30 минут на формирование отчета о тестировании, ведение логов тестирования и т.п. заключительную отчетность.

Весь учет мы ведем в джире и наша первоначальная оценка хранится там же. Равно как и конечная оценка. Зная оценку которую мы даем в самом начале и оценку, которую мы получаем  по окончании тестирования мы имеем 30%  статистически подтвержденную поправку. Эти самые 30% ни что иное, как время потраченное тестировщиками на ретестирование багов или доработок, исследование бага или фича, ошибки в оценке (в основной массе, все таки, ретестирование багов и исследование проблем).

Регрессионное тестирование имеет вид описанный в моей заметке про чеклисты. Тесты уже оценены и мы легко получаем время, необходимое для этого типа тестирования.

Как определяем ресурсы

У нас бывают праздники. У нас бывают выходные. Мы ходим на курсы.  А еще у нас есть оговоренные сроки, которые хочет увидеть наш PM. И поэтому у нас есть таблица в Excel для 4 тестировщиков растянутая на несколько недель/месяцев. Грубо говоря у нас план работ в котором можно указать ложное: тестировщики 8 часов в день занимаются тестированием, но стоит правильное: тестировщики 4 часа в день, наверное, смогут заниматься только тестированием. Это спорное утверждение раскрывается далее.

Включить риски и опыт

Итак у нас есть количество человек + количество человеко-часов, необходимых для завершения работы (не забываем про 30% на ретестирование). И что - будем планировать тестирование 8 часов на 5 дней? - Черта лысого.

Во-первых, у нас есть митинги. Компания крупная - митингов много. Чем крупнее компания тем больше затрат на митинги.

Во-вторых, мы общаемся. Компания крупная - круг общения большой. Чем крупнее компания, тем больше приходиться тратить времени на общение.

В третьих команда молодая и два из четверых тестировщика еще не отработали испытательные 3 месяца. Следовательно - имеет место передача опыта. Кто читал "Мифический человеко-месяц" поймет - новичок замедляет скорость команды (Сейчас это уже не актуально - статья начиналась готовиться много месяцев назад, но абзац оставляю, поскольку он также полезен для планирования, как один из ресурсозатратных активностей).

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

А еще мы ходим пить кофе с печеньками, когда устанем ;)

Как все это учитывается? 

Все это принято называть non-testing активности и environment downtimes.

Копится статистика простоев, митингов, коммуникаций и прочих активностей специалистов, которая потом отнимается от 8 часов. Вообще подсчитано, что на час тестирования мы имеем час не-тестирования.  Т.е. в день (грубо говоря) тестировщики в проекте тратят 4 часа на тестирование и 4 часа на все остальное. Подозреваю, что эта оценка может варьировать от проекта в проект. В своей компании я встречал проекты в которых тест-активности могут занимать в среднем 6 из 8 часов.

Если кто читал  Scrum и XP: заметки с передовой то наши часы на тестирование ничто иное как идеальные человеко часы для тестировщика.

Построить план

Итак при планировании мы окончательно имеем и используем подтвержденные жизнью данные:

1. Затраты на тестирование,

2. 30% на ретестирование,

3. non-testing time из расчета 60% работы 40% тестирования (такое соотношение не дает расслабляться). Non testing time включается в себя:
- Environment Downtimes: простои из-за сбоев в тестовом окружении, не поданный во время билд,
- non-testing activities: статистику по коммуникациям (письма, совещания, обсуждения, летучик) и организационным затратам времени (корпоративные совещания, настройка оборудования).

Вся информация сводится в файл (см. ниже) и отслеживается каждый день.

Как мы следим за работой

Предположим у нас есть таблица планирования нашей трудозатрат:

1	Функциональное тестирование (ч-д)	100
2	Регрессионное тестирование (ч-д)	100
	Сумма затрат на тестирование (ч-д)	200
3	Ретестирование, исследование проблем, % от суммы тестирования	30
	Ретестирование, исследование проблем, ч-д	60
	Сумма затрат на Тестирование + Ретестирование	260
4	Environment downtimes (простои из за технических/технологических причин)  в день на одного человека (историческая статистика), ч-д	0,9
5	Non testing activities (организационные потери времени), ч-д	2,0

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

Прошу прощения что все на английском,  но надеюсь не вызовет больших проблем.

Итак на таблице для каждого тестировщика проставлены запланированные траты времени. Последние две колонки отображают их суммарные запланированные затраты на тестирование и простои. После плановых затрат тестировщиков идут ряды основных метрик - запланированных (Planned) и получаемых (Results). Сравнивая метрики [Remain to complete] и [Testing to complete] мы получаем разницу между запланированным остатком трудоемкости и реальным. Эта разница позволяет нам держать руку на пульсе - насколько мы отстаем или забегаем вперед. На основе этих волшебных циферок можно получить burndown диаграмму.

Некоторые кейсы для тренировки.

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

1. Может так случиться что вы рассчитали средние потери по тестовому окружению, но в течении всего цикла потерь не было, а за 3 дня до окончания тестирования сервер слетел. К вам приходит PM и говорит – потерь времени раньше не было – почему оставшиеся 3 дня так важны?

2. Лид разработчиков просит протестировать исправленную фичу, но просит это сделать по быстрому – чуть-чуть. На вопрос – почему эта фича, не была включена в scope, не оценена и к тому же предлагается в тестирование в то время, когда регрессия уже идет полным ходом . Dev lead улыбается и говорит: Ну, ты знаешь, как бывает. Вам предстоит выяснить как измениться конечная дата тестирования, с учетом что на это время отодвинется регрессия.

3. В вашей команде случился незапланированный отпуск, в связи с рождением ребенка/длительной болезнью сотрудника/алкогольным отравлением сотрудника за 3 дня до окончания тестирования. И + еще к вам не следующей неделе придет новичек, который о проекте и специфике бизнесса знает только по наслышке. У вас есть полторы недели до окончания тестирования — вам их хватит?

4. Один из тестировщиков отводит на работу с релизом только 50% своего времени, поскольку перешел в другой проект и осваивается там. Известно, что через 2 недели он вообще прекратит работу в текущем проекте. Как это повлияет на дату окончания тестирования?