менения тест-кейса к ней.

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

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

щены на машину для пользователей.

Один мой друг сравнивает фича с человеком: если это ребенок, то

он постоянно меняется; если же он взрослый, то изменений в нем

намного меньше и сами изменения менее радикальны — сравните

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

281

того же ребенка, когда ему 6 и 12 лет; и теперь взрослого, когда

ему 42 и 48 лет. Идея, я думаю, понятна.

Чем меньше будет изменений в фича, тестирование которой ав-

томатизировано, тем меньше времени будет затрачено на под-

держку. Поддержка же порой превращается в кошмар

• с чередой красноглазых бессонных ночей перед монитором,

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

вильно, и

• со сладостным искушением все бросить и поехать с Лелей

в Ялту.

КАК:

Это создание инфраструктуры, позволяющей с легкостью и про-

стотой

• поддерживать существующие автоскрипты;

• создавать новые автоскрипты.

Инфраструктура автоматизации регрессивного тестирования должна

• с одной стороны, быть образцом программистского мас-

терства;

• с другой — воплощать наиболее эффективные подходы

к автоматизации, возможные при данном ПО для автома-

тизации (например, силк-тесте);

• с третьей — учитывать нюансы технологий именно этой

интернет-компании.

В заключение нашего краткого разговора об автоматизации рег-

рессивного тестирования я хочу открыть вам одну истину:

Суровая правда жизни заключается в том, что 100%-я авто-

матизация регрессивного тестирования сколько-нибудь серь-

езного веб-проекта — это миф.

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

убедиться, что это миф.

Если ваша компания решила заняться автоматизацией рег-

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

сколько нужно, чтобы найти настоящего профессионала, а

найдя его, дать ему дышать и не ожидать, что 100% тест-ком-

плектов когда-либо будут автоматизированы.

Это все о решении основной проблемы регрессивного тестирования.

282

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

Хорошая идея — это предусмотреть окончание регрессивного

тестирования за 2—3 дня до релиза:

• с одной стороны, у нас будет в запасе 2—3 дня, которые мы

можем использовать для завершения регрессивного тести-

рования, если наша оценка того, сколько дней оно займет,

была неверна.

• с другой — эти 2—3 дня можно потратить на тест-сдачи,

распределив между тестировщиками части ПО.

А дальше идет релиз...

Краткое подведение итогов

1. Тест-смета необходима для приведения к одному знаменателю

потребностей компании и возможностей тестировщиков.

2. Каждый этап тестирования начинается/заканчивается при на-

ступлении условия начала/завершения.

3. Тест-план — это документ, обобщающий и координирующий

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

4. Приоритезация тест-комплектов и тест-кейсов имеет наиважней-

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

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

5. Из всех способов решения проблемы асинхронизации ресурсов и

объема регрессивного тестирования наем новых людей самый

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

6. Лучше хороший черноящичный тестировщик, чем один или боль-

ше плохих инженеров по автоматизации регрессивного тести-