егрессивное тестирование как второй этап исполнения тес-

Ртирования — это проверка того, что изменения, сделан-

ные в ПО (для того, чтобы мир увидел новые фича), не поло-

мали старые фича.

Допустим, у нас есть 5 тест-комплектов с тест-кейсами для новых

фича, а также 21 тест-комплект с тест-кейсами для старых фича.

Ситуация эта рождает как минимум два вопроса:

1. Какие из этих 21 тест-комплекта выбрать, чтобы:

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

ломаны?

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

рования (например, 5 рабочих дней + два выходных дня,

которые вполне могут стать рабочими)?

2. Что делать с регрессивным тестированием дальше, ко

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

(тест-комплекты, которые проверяли новые фича, прим

кнут к остальным тест-комплектам и станут кандидатами

для регрессивного тестирования) и еще, скажем, 10 после

следующего релиза и т.д. (постоянно нарастающий снеж

ный ком)?

271

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

273

Итак, две темы:

1. Выбор тест-комплектов для регрессивного тестирования.

2. Решение проблемы противоречия между ограничен-

ными ресурсами (например, время на регрессивное тес-

тирование) и перманентно увеличивающимся количест-

вом тест-комплектов.

Кстати, как обычно, я излагаю личное видение предмета. В разных

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

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

альности компании, в которой будете работать.

Выбор тест-комплектов

для регрессивного тестирования

Первый вопрос: "Как узнать, какие части ПО могут быть поломаны?"

С одной стороны, как мы уже не раз говорили, в сложной системе,

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

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

ние кода, с другой — мы все-таки можем предполагать:

• к какой части ПО принадлежат новые фича (например,

фича из спека #5419 "Новые функциональности для Кор-

зины" принадлежат к "Корзине") и

• какие старые фича напрямую зависят от части ПО с

новыми фича (например, компонент "Оплата" использует

данные (по ценам книг), которые передаются ей компонен-

том "Корзины").

Решение следующее:

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

нас будут тест-комплекты, проверяющие часть ПО, к которой

принадлежат новые фича.

Например,

при новых фича для "Корзины" в первую группу идут все тест-комплек-

ты, непосредственно тестирующие "Корзину".

Рациональное объяснение:

если программист напортачил с кодом, то фича, тестируемые тест-

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

как являются частью ПО с измененным кодом.

274

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

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

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

зависят от части ПО с новыми фича.

Например,

при новых фича для "Корзины" во вторую группу мы можем отнести

тест-комплекты, проверяющие "Оплату".

Рациональное объяснение: