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

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

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

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

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

ный ком)?

271

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

273

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например,

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

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

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

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

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

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

274

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

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

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

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

Например,

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

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

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

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

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

части ПО, также нуждается в модификации (о необходимости ко-

торой и продюсер, и программист могли просто... забыть).

Например, при изменениях в коде "Корзины" был легитимно (согласно

спеку) изменен формат куки (cookie — файл с информацией о вашем

заказе, хранящийся на вашем компьютере и используемый веб-сер-

вером). Часть же ПО, которая заведует "Оплатой", не была модифи-

цирована (или была модифицирована неверно), и она (эта часть ПО)

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

не представляется возможным.

Есть и третья группа, к которой мы подберемся чуть позднее.

Пока же допустим, что группы только две.

Проиллюстрируем:

Группа

Номер тест-комплекта

1

#XS1111

#TS1222

#TS1333

2

#TS2444

#TS2555

#TS2777

#TS2888

#TS2999

Теперь вопрос второй: "Как уложиться в срок, выделенный для

регрессивного тестирования?"

Допустим, что у нас есть два тестировщика и неделя времени, т.е.

80 человеко-часов (112 — с выходными, 336 — без сна и отдыха).

Вопрос: Сможем ли мы исполнить все 8 тест-комплектов за эти

80 часов?

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

275