его автоскрипты все-таки исполняют пару из 10 автоматизи-

рованных им тест-комплектов. В следующий релиз все повторя-

ется заново, и в итоге менеджер решает уволить г-на Говоркова

и взять на его место обыкновенного черноящичного тестиров-

щика — будет дешевле и эффективнее.

Я ничуть не утрирую. Подобные ситуации происходят в боль-

шинстве случаев после принятия компанией решения об автома-

тизации регрессивного тестирования.

Почему так происходит?

Автоматизация регрессивного тестирования заключается в соз-

дании целой тестировочной инфраструктуры с библиотеками

кода, базами данных, системами отчетности и прочими вещами.

Создание такой инфраструктуры — дело очень и очень непростое.

Иногда менеджмент, желая получить результат быстро и любой це-

ной, давит на спеца по автоматизации, и даже если последний добро-

совестно создает инфраструктуру для автоматизации, то он это дело

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

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

стоящим менеджментом: "За первый квартач 2005 года было авто-

матизировано 12 тест-комплектов, содержащих 174 тест-кейса".

Конечно, все эти автоскрипты не будут вскоре функционировать

без трудоемкой поддержки, но кого это волнует? Начальство до-

вольно, и, значит, все "Хоккей".

Но допустим, что менеджмент все понимает и дает карт-бланш

на создание Инфраструктуры с большой буквы "Ай".

ПО — это живое существо. Оно постоянно меняется, и авто-

матизация, связанная с ПО, должна соответственно меняться

одновременно с ним. Таким образом, только поддержание (main-

tenance) существующих автоскриптов — задача, требующая боль-

ших профессиональных усилий, не говоря уже о написании но-

вых автоскриптов.

280

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

Я предлагаю очень простой подход к определению эффективно-

сти автоматизированного регрессивного тестирования. Посмот-

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

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

общие затраты на автоматизацию на количество багов — резуль-

татом будет стоимость нахождения одного бага. Сделайте то же

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

рования и сравните. В 90% случаев стоимость бага, найденного

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

найденного вручную. И очень большой шанс, что вы подумаете:

а зачем вообще нужна ТАКАЯ автоматизация?..

Кстати,

так всегда получается, что в процессе автоматизирования находят

больше багов, чем при исполнении автоматизации.

Советую также сравнить время, потраченное на автоматизацию

(и ее поддержку) для некого тест-комплекта, с временем на исполне-

ние этого же тест-комплекта вручную. Гарантирую, что результаты

удивят, в смысле неприятно удивят, и не в пользу автоматизации.

Таким образом, наиважнейшее значение приобретает профессио-

нализм специалиста по автоматизации.

Профессионализм такого спеца заключается не только в его про-

граммистских навыках, но и в том, как четко он представляет:

• ЧТО автоматизировать и

• КАК автоматизировать.

ЧТО:

Лучший кандидат для автоматизации — это тест-кейс для тести-

рования старой, устоявшейся фича. Автоматизируя его, мы, по

крайней мере, можем быть уверены, что автоскрипт не нужно

будет переписывать из-за изменения фича и соответственно из-