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

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

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

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

терфейс веб-сайта был в нескольких местах незначительно изменен.

Исполнение тестирования. Стадия 2: регрессивное тестирование

279

Например, в автоскрипте может быть инструкция о нажатии

кнопки "Вход " на такой-то странице, и если агент, исполняющий

автоскрипт, не "видит" кнопки с именно таким названием, то

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

Г-н Говорков, говорит "фигня вопрос ", тратит на починку скрип-

тов пару недель и в последний день регрессивного тестирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

280

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

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

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

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

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

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

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

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

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

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

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

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

Кстати,

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

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

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

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