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

Ответ: Очевидно, что для этого нужно знать, сколько времени

занимает исполнение каждого из этих тест-комплектов.

Вопрос: Как это узнать?

Ответ: Каждая компания делает по-своему. В одних компаниях

есть специальные механизмы трэкинга времени, потраченного на

исполнение каждого из тест-комплектов (иногда даже считается

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

го исполнения тестировщик указывает время исполнения в шапке

тест-комплекта. В общем разные бывают варианты, но суть в том,

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

мает исполнение каждого тест-комплекта.

"Примерно" — потому что исполнение тест-комплекта может

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

няет (хотя есть и другие факторы). На практике, особенно в слу-

чаях со сложными и трудоемкими тест-комплектами, быстрее

справляется с задачей тот, кто уже однажды исполняв данный

конкретный тест-комплект.

Допустим, что мы знаем, сколько времени занимает исполнение

каждого тест-комплекта.

Оговорка: в реальной жизни исполнение тест-комплектов, как

правило, занимает гораздо меньше времени, чем в примере ниже,

но нам нужна наглядность.

Группа

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

Время на исполнение

(в часах)

1

#TS1111

10

#TS1222

15

#TS1333

17

2

#TS2444

18

#TS2555

12

#TS2777

14

#TS2888

26

#TS2999

19

Итого, 131 час, что больше запланированных 80, и даже если мы

будем работать в выходные, то не хватает 19 часов (131 - 112).

Эти 19 часов могут быть, например, распределены на работу в

сверхурочное время: примерно 2 часа 40 минут плюс к нашим

276

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

восьми часам семь раз в неделю (19 : 7). Кстати, так и поступают

во многих стартапах.

Но допустим, что наш www.testshop.rs не относится к этим мно-

гим и славится человечным отношением к своим работникам.

Итак, нам, гуманистам, не хватает 51 часа (131- 80) для исполне-

ния регрессивного тестирования. Что можно сделать? Среди прочих

вещей, таких, как заимствование сотрудников из других отделов,

можно сделать следующее: у нас есть приоритет каждого из тест-

комплектов. Так давайте же исполним самые приоритетные из них!

Группа

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

Время на исполнение

Приоритет

(в часах)

1

#TS1111

10

1

#TS1222

15

3

#TS1333

17

4

2

#TS2444

18

4

#TS2555

12

2

#TS2777

14

1

#TS2888

26

3

#TS2999

19

2

Если мы исполним тест-комплекты

• только 1-го приоритета, то регрессивное тестирование возь-

мет 24 часа (10+ 14);

• только 1-го и 2-го, то — 55 часов (24 + 12 + 19);

• только 1, 2 и 3-го, то — 96 часов (55 + +5 + 26), это нам не

подходит.

Итак, мы исполняем тест-комплекты 1-го и 2-го приоритетов.

Оставшиеся 25 часов (80 - 55) можно отдать на исполнение, на-

пример:

• спека #1222 (15 часов), либо

• спека #2888 (26 часов), либо

• исполнить наиболее приоритетные тест-кейсы из обоих этих

тест-комплектов (самая лучшая идея).

Концепция, думаю, понятна.

Кстати,

определение списка тест-комплектов для регрессивного тестирования —

это, как правило, прерогатива менеджмента.

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

277

Теперь о третьей группе.

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

вую, ни во вторую группы. Но они тоже нуждаются в регрессив-

ном тестировании, так как изменение ПО может каким-то обра-

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

застрахован. Для того чтобы затронуть все тест-комплекты, для

регрессивного тестирования каждого релиза в порядке очереди

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

существующие тест-комплекты были исполнены хотя бы один

раз в определенный период, например в полгода. При недостат-

ке времени для исполнения тест-комплектов из группы 3 ре-

комендую исполнять лишь самые приоритетные тест-кейсы

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

сивном тестировании данного релиза.

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