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