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 тест-комплектов и один релиз в месяц,
то, если исполнять по 15 тест-комплектов каждый релиз, за 3 месяца
можно исполнить их все.
Решение проблемы противоречия
Проблема противоречия между ограниченными ресурсами (напри-
мер, время на регрессивное тестирование) и постоянно растущим
количеством тест-комплектов решается следующими способами:
а. Приоритезация тест-комплектов и тест-кейсов.
б. Оптимизация тест-комплектов.