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

«Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах», Роман Савин, Москва, Дело, 2007. 104 страница, 259-263:

Test Estimation (тест-смета). Как правило, в интернет-компаниях существует расписание рели- зов. К этому расписанию привязано расписание тестирования (QA Schedule), которое определяет сроки каждой стадии процесса тес- тирования.

"Как правило" было употреблено из-за того, что в некоторых компаниях такого понятия, как "Расписание", не существует в принципе.

Итак, допустим, что

• на подготовку к тестированию дается две недели (10 рабочих дней (80 часов) + 4 выходных дня (32 часа), которые элементарно могут стать рабочими);
• на исполнение тестирования также дается две недели (10 рабочих дней (80 часов) + 4 дня выходных дня (32 часа), которые также элементарно могут стать рабочими),

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

• тестирование новых фича по созданным тест-кейсам;
• регрессивное тестирование.

Проблема в том, что, как бы ударно мы ни работали, мы можем выполнить лишь определенный объем работы и возникает конфликт между

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

Чтобы уравновесить желаемое и реальное, используют сметы (estimation).

Тестировщик готовит тест-смету (Test Estimation), которая вклю- чает:

• предварительную оценку времени, необходимого на под- готовку к тестированию;
• предварительную оценку времени, необходимого на тести- рование новых фича.

Как тестировщик готовит тест-смету? Очень просто:

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

Пример

Для создания тест-сметы тестировщику был дан спек #1299 "Новые функциональности поиска". Тестировщик предоставил своему менеджеру следующее:

• потребуется 50 часов на написание тест-кейсов и 20 часов на написание тест-тулов;
• потребуется 60 часов на исполнение этих тест-кейсов.

Таким образом, тестировщик полностью укладывается в график по подготовке к тестированию (80 - 50-20 >0). Оставшиеся 10 часов можно будет использовать для помощи своим коллегам и/или как резерв на случай, если оценка тестировщика была неверной и на подготовку в реальности потребуется больше времени.

Сложнее обстоит дело с исполнением тестирования. На регрессивное тестирование остается только 20 часов (80 - 60). Будет ли этих 20 часов достаточно, чтобы закончить регрессивное тестирование в срок? Это зависит от нескольких факторов, основные из них:

• значительность релиза, например: имело ли место серьезное изменение архитектуры ПО? На сколько процентов изменилось количество строк кода? Были ли добавлены новые критические функциональности, интегрированные со старым кодом? и пр.;
• трудоемкость тест-комплектов, которые нужно исполнить для регрессивного тестирования (подробно поговорим о нюансах регрессивного тестирования через полчаса).

Ответ на последний вопрос ("будет ли достаточно 20 часов?"), как и сам процесс уравновешивания потребностей бизнеса и возможностей работников, — это епархия менеджмента, а мы люди простые, и наше дело — дать предварительные оценки, по возможности приближенные к недалекой реальности.

Итак, как создать тест-смету?

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

Кстати,

после того как тест-смета готова, рекомендую увеличить ее на 10%, чтобы учесть такие непредвиденные обстоятельства.

Вот факторы, которые я рекомендую принять во внимание при составлении сметы:

• предполагаемая сложность новых фича. Чем они сложнее, тем больше нюансов всплывет при под- готовке и исполнении и тем больше времени понадобится на тестирование;
• есть ли у вас опыт тестирования похожих фича. Например, если вы эксперт в тестировании оплаты, то для вас будет проще и быстрее протестировать добавление еще одного вида кредитной карточки по сравнению с тестировщиком, который никогда кредитных карточек не касался;
• опыт работы на прошлых проектах с теми же продюсе ром и программистом. Например, одни программисты пишут удивительно чистый код, всегда проводят юнит-тестирование и с охотой кооперируются с тестировщиками. Другие же бросают куски кода в проект, как грязь на стену, считают юнит-тестирование вещью, не подобающей для компьютерного гения, и не склонны кооперироваться ни с кем, кроме виртуальных солдат игры Halo. Следовательно, во втором случае мы должны заложить больше времени на наше тестирование;

• будет ли интеграция нашего ПО с ПО наших бизнес-партнеров — вендоров (vendor), например интеграция с ПО платежной системы. Тест-конфигурация выглядит так: наша тест-машина "разговаривает" с их тест-машиной. Соответственно если что-то не в порядке с их тест-машиной, то проблема решается сложнее, чем при локальном тестировании, когда вы заносите баг и наш программист его ремонтирует. В случае с их тест-машиной

  • тестировщик связывается с менеджером проекта (с нашей стороны);
  • последний должен позвонить вендору;
  • человек со стороны вендора должен найти ответственного программиста;
  • ответственный программист может быть занят
  • и т.д. и т.п.

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

• нужны ли тулы для автоматизации тест-кейсов? Тест-тулы, как правило, создаются во время написания тест- кейсов как средство для облегчения исполнения тест-кейса, например:

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

В одних случаях тестировщик может сам написать такой тул, например, на языках Java или Python. В других случаях написание тула в помощь тестировщикам — это дело программиста.

Кстати, в некоторых компаниях внутри департамента качества существуют специальные отделы по созданию тест-тулов.

Вы должны подкорректировать тест-смету в зависимости от ва- шей оценки того:

• сколько времени у вас займет создание (включая тестиро- вание) такого тула (если тул создается вами, а не программистом);
• сколько времени этот тул сможет реально сэкономить во время тестирования новых фича.

Итак, при составлении тест-сметы используем вышеперечисленные факторы, слушаем свои опыт и интуицию и советуемся с коллегами.

22.02.2018