tестирование dot com

Савин Роман

• потребуется 50 часов на написание тест-кейсов и 20 часов на

написание тест-тулов;

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

Таким образом, тестировщик полностью укладывается в график по

подготовке к тестированию (80 - 50-20 >0). Оставшиеся 10 часов

можно

будет использовать для помощи своим коллегам и/или как ре-

Исполнение тестирования. Стадия 1: тестирование новых фича

261

зерв на случай, если оценка тестировщика была неверной и на подго-

товку в реальности потребуется больше времени.

Сложнее обстоит дело с исполнением тестирования. На регрессивное

тестирование остается только 20 часов (80 - 60). Будет ли этих 20 ча-

сов достаточно, чтобы закончить регрессивное тестирование в срок?

Это зависит от нескольких факторов, основные из них:

• значительность релиза, например: имело ли место серьезное

изменение архитектуры ПО? На сколько процентов изменилось

количество строк кода? Были ли добавлены новые критические

функциональности, интегрированные со старым кодом? и пр.;

• трудоемкость тест-комплектов, которые нужно исполнить для

регрессивного тестирования (подробно поговорим о нюансах

регрессивного тестирования через полчаса).

Ответ на последний вопрос ("будет ли достаточно 20 часов?"), как и

сам процесс уравновешивания потребностей бизнеса и возможностей

работников, — это епархия менеджмента, а мы люди простые, и наше

дело — дать предварительные оценки, по возможности приближенные

к недалекой реальности.

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

Сложность заключается в том, что тест-смета создается после

того, как прочитан спек, а между чтением спека и работой по не-

му такая же дистанция, как между теоретиком и практиком кун-

фу. Во время работы над спеком, т.е. создания по нему тест-

кейсов, открываются такие грани и нюансы, о существовании ко-

торых было трудно (если не невозможно) предположить во время

простого прочтения. Кроме того, всегда есть непредвиденные

обстоятельства, среди которых может быть, например, неприлич-

но большое количество блокирующих багов.

Кстати,

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

чтобы учесть такие непредвиденные обстоятельства.

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

составлении сметы:

• предполагаемая сложность новых фича.

Чем они сложнее, тем больше нюансов всплывет при под-

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

на тестирование;

• есть ли у вас опыт тестирования похожих фича.

Например, если вы эксперт в тестировании оплаты, то для

вас будет проще и быстрее протестировать добавление

262

Тестирование Дот Ком. Часть 3

еще одного вида кредитной карточки по сравнению с

тестировщиком, который никогда кредитных карточек не

касался;

• опыт работы на прошлых проектах с теми же продюсе

ром и программистом.

Например, одни программисты пишут удивительно чистый

код, всегда проводят юнит-тестирование и с охотой

кооперируются с тестировщиками. Другие же бросают

куски кода в проект, как грязь на стену, считают юнит-

тестирование вещью, не подобающей для компьютерного

гения, и не склонны кооперироваться ни с кем, кроме

виртуальных солдат игры Halo. Следовательно, во втором

случае мы должны заложить больше времени на наше тес-

тирование;

• будет ли интеграция нашего ПО с ПО наших бизнес-парт

неров — вендоров (vendor),

например интеграция с ПО платежной системы. Тест-кон-

фигурация выглядит так: наша тест-машина "разговари-

вает" с их тест-машиной. Соответственно если что-то не в

порядке с их тест-машиной, то проблема решается слож-

нее, чем при локальном тестировании, когда вы заносите

баг и наш программист его ремонтирует. В случае с их

тест-машиной

• тестировщик связывается с менеджером проекта (с на-

шей стороны);

• последний должен позвонить вендору;

• человек со стороны вендора должен найти ответст-

венного программиста;

• ответственный программист может быть занят