tестирование dot com
Шрифт:
альности компании, в которой будете работать.
Выбор тест-комплектов
для регрессивного тестирования
Первый вопрос: "Как узнать, какие части ПО могут быть поломаны?"
С одной стороны, как мы уже не раз говорили, в сложной системе,
которой является более или менее серьезный веб-сайт, во многих
случаях сверхсложно определить, где и как откликнется измене-
ние кода, с
• к какой части ПО принадлежат новые фича (например,
фича из спека #5419 "Новые функциональности для Кор-
зины" принадлежат к "Корзине") и
• какие старые фича напрямую зависят от части ПО с
новыми фича (например, компонент "Оплата" использует
данные (по ценам книг), которые передаются ей компонен-
том "Корзины").
Решение следующее:
Первой группой кандидатов для регрессивного тестирования у
нас будут тест-комплекты, проверяющие часть ПО, к которой
принадлежат новые фича.
Например,
при новых фича для "Корзины" в первую группу идут все тест-комплек-
ты, непосредственно тестирующие "Корзину".
Рациональное объяснение:
если программист напортачил с кодом, то фича, тестируемые тест-
комплектами первой группы, будут поломаны скорее всего, так
как являются частью ПО с измененным кодом.
274
Тестирование Дот Ком. Часть 3
Второй группой кандидатов для регрессивного тестирования у
нас будут тест-комплекты, проверяющие старые фича, которые
зависят от части ПО с новыми фича.
Например,
при новых фича для "Корзины" во вторую группу мы можем отнести
тест-комплекты, проверяющие "Оплату".
Рациональное объяснение:
если даже программист НЕ сломал ничего, есть большая вероят-
ность того, что код фича, напрямую зависящей от измененной
части ПО, также нуждается в модификации (о необходимости ко-
торой и продюсер, и программист могли просто... забыть).
Например, при изменениях в коде "Корзины" был легитимно (согласно
спеку) изменен формат куки (cookie — файл с информацией о вашем
заказе, хранящийся на вашем компьютере и используемый веб-сер-
вером). Часть же ПО, которая заведует "Оплатой", не была модифи-
цирована (или
просто не понимает новый формат куки, а следовательно, купить книгу
не представляется возможным.
Есть и третья группа, к которой мы подберемся чуть позднее.
Пока же допустим, что группы только две.
Проиллюстрируем:
Группа
Номер тест-комплекта
1
#XS1111
#TS1222
#TS1333
2
#TS2444
#TS2555
#TS2777
#TS2888
#TS2999
Теперь вопрос второй: "Как уложиться в срок, выделенный для
регрессивного тестирования?"
Допустим, что у нас есть два тестировщика и неделя времени, т.е.
80 человеко-часов (112 — с выходными, 336 — без сна и отдыха).
Вопрос: Сможем ли мы исполнить все 8 тест-комплектов за эти
80 часов?
Исполнение тестирования. Стадия 2: регрессивное тестирование
275
Ответ: Очевидно, что для этого нужно знать, сколько времени
занимает исполнение каждого из этих тест-комплектов.
Вопрос: Как это узнать?
Ответ: Каждая компания делает по-своему. В одних компаниях
есть специальные механизмы трэкинга времени, потраченного на
исполнение каждого из тест-комплектов (иногда даже считается
время на исполнение каждого тест-кейса), в других после каждо-
го исполнения тестировщик указывает время исполнения в шапке
тест-комплекта. В общем разные бывают варианты, но суть в том,
что необходимо хотя бы примерно знать, сколько времени зани-
мает исполнение каждого тест-комплекта.
"Примерно" — потому что исполнение тест-комплекта может
варьироваться в зависимости, например, от того, кто его испол-
няет (хотя есть и другие факторы). На практике, особенно в слу-
чаях со сложными и трудоемкими тест-комплектами, быстрее
справляется с задачей тот, кто уже однажды исполняв данный
конкретный тест-комплект.
Допустим, что мы знаем, сколько времени занимает исполнение
каждого тест-комплекта.
Оговорка: в реальной жизни исполнение тест-комплектов, как