testirovanie_dot-com
.pdfИсполнение тестирования. Стадия 1: тестирование новых фача |
269 |
14. Условия приостановки/возобновления тестирования — это условия, при которых тестирование должно быть остановлено/ продолжено.
Например,
к условию приостановки можно отнести количество П1 багов, при котором (и/или после которого), по мнению автора (-ров) тест-плана, дальнейшее продолжение тестирования не имеет смысла (например, 7 П1). Соответственно условием возобновления должно быть количество оставшихся П1 багов (после ремонта и регрессивного тестирования),котороепозволяетвозобновить тестирование(например,2П1).
15.Ответственные лица — подробный список товарищей (продюсеров, программистов, тестировщиков и пр.), контактная информация и обязанности каждого из них. Такой список может включать лиц со стороны вендора.
16.Тренинг — тренинг, необходимый для данного проекта.
Например,
при соответствующей ситуации нужно указать, что для создания тесткейсов тестировщику необходимо прослушать семинар "Банковская система США".
17.Расписание — сроки, имеющие отношение к тестированию данного проекта:
•дата замораживания спеков;
•дата начала подготовки к тестированию;
•дата завершения подготовки к тестированию;
•дата интеграции и замораживания кода;
•дата начала тестирования новых фича;
•дата завершения тестирования новых фича;
•дата начала регрессивного тестирования;
•дата завершения регрессивного тестирования.
18.Оценка риска — предположение о том, как и что может пой ти по неправильному пути и что мы в этом случае предпримем.
Например,
если мы не успеваем закончить тестирование (не выполняем требование "Условия завершения", например, "все тест-кейсы исполнены") в срок, то придется задерживаться на работе и приходить в офис в выходные и праздники.
Кстати, если народ приходит в выходные и праздники, то компания должна, по крайней мере, кормить его обедом.
270 |
ТестированиеДот Ком. Часть3 |
|
19.Прочие положения — вещи, не вошедшие в тест-план, о которых неплохо было бы упомянуть.
20.Утверждения — это подписи лиц, которые утвердили тестплан. Чем больше будет таких подписей, тем лучше. По крайней мере, нужны подписи менеджера тестировщика, составившего план, самого тестировщика, продюсера и программиста.
21.Приложения — например, расшифровка терминов и аббревиатур, используемых в тест-плане.
Это все о тест-планах и о первой стадии исполнения тестирования.
ИСПОЛНЕНИЕТЕСТИРОВАНИЯ. СТАДИЯ2:
РЕГРЕССИВНОЕ ТЕСТИРОВАНИЕ
• ВЫБОР ТЕСТ-КОМПЛЕКТОВ ДЛЯ РЕГРЕССИВНОГО ТЕСТИРОВАНИЯ
•РЕШЕНИЕ ПРОБЛЕМЫ ПРОТИВОРЕЧИЯ
Регрессивное тестирование как второй этап исполнения тестирования — это проверка того, что изменения, сделанные в ПО (для того, чтобы мир увидел новые фича), не поло-
мали старые фича.
Допустим, у нас есть 5 тест-комплектов с тест-кейсами для новых фича, а также 21 тест-комплект с тест-кейсами для старых фича. Ситуация эта рождает как минимум два вопроса:
1.Какие из этих 21 тест-комплекта выбрать, чтобы:
•проверить именно те части ПО, которые могли быть поломаны?
•уложиться в срок, выделенный для регрессивного тестирования (например, 5 рабочих дней + два выходных дня, которые вполне могут стать рабочими)?
2.Что делать с регрессивным тестированием дальше, ко гда после релиза к 21 тест-комплекту прибавятся еще 5 (тест-комплекты, которые проверяли новые фича, прим кнут к остальным тест-комплектам и станут кандидатами для регрессивного тестирования) и еще, скажем, 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 |
Ответ: Очевидно, что для этого нужно знать, сколько времени занимает исполнение каждого из этих тест-комплектов.
Вопрос: Как это узнать?
Ответ: Каждая компания делает по-своему. В одних компаниях есть специальные механизмы трэкинга времени, потраченного на исполнение каждого из тест-комплектов (иногда даже считается время на исполнение каждого тест-кейса), в других после каждого исполнения тестировщик указывает время исполнения в шапке тест-комплекта. В общем разные бывают варианты, но суть в том, что необходимо хотя бы примерно знать, сколько времени занимает исполнение каждого тест-комплекта.
"Примерно" — потому что исполнение тест-комплекта может варьироваться в зависимости, например, от того, кто его исполняет (хотя есть и другие факторы). На практике, особенно в случаях со сложными и трудоемкими тест-комплектами, быстрее справляется с задачей тот, кто уже однажды исполняв данный конкретный тест-комплект.
Допустим, что мы знаем, сколько времени занимает исполнение каждого тест-комплекта.
Оговорка: в реальной жизни исполнение тест-комплектов, как правило, занимает гораздо меньше времени, чем в примере ниже, но нам нужна наглядность.
Группа |
Номертест-комплекта |
Времянаисполнение |
|
|
(в часах) |
|
|
|
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 минут плюс к нашим
Исполнение тестирования. Стадия 2: регрессивное тестирование |
277 |
Теперь о третьей группе.
Как правило, большая часть тест-комплектов не входит ни в первую, ни во вторую группы. Но они тоже нуждаются в регрессивном тестировании, так как изменение ПО может каким-то образом повлиять и на каждую из них, здесь, как говорится, никто не застрахован. Для того чтобы затронуть все тест-комплекты, для регрессивного тестирования каждого релиза в порядке очереди выделяется по несколько тест-комплектов с расчетом, чтобы все существующие тест-комплекты были исполнены хотя бы один раз в определенный период, например в полгода. При недостат-
ке времени для исполнения тест-комплектов из группы 3 рекомендую исполнять лишь самые приоритетные тест-кейсы
каждого тест-комплекта, выбранного для исполнения при регрессивном тестировании данного релиза.
Например, если у нас есть 45 тест-комплектов и один релиз в месяц, то, если исполнять по 15 тест-комплектов каждый релиз, за 3 месяца можно исполнить их все.
Решениепроблемы противоречия
Проблема противоречия между ограниченными ресурсами (например, время на регрессивное тестирование) и постоянно растущим количеством тест-комплектов решается следующими способами:
а. Приоритезация тест-комплектов и тест-кейсов. б. Оптимизация тест-комплектов.
в. Наем новых тестировщиков.
г. Автоматизация регрессивного тестирования.
а. О пользе приоритезации мы уже говорили. Странно, но во мно гих компаниях предпочитают изматывать людей, вместо того чтобы приоритезировать тест-комплекты и тест-кейсы и испол нять лишь те из них, которые реально важны.
б. Оптимизация тест-комплектов. Многие старые тест-комплекты могут быть оптимизированы в смысле
•уменьшения количества тест-кейсов и/или
•упрощения исполнения тест-кейсов.
Часто имеет смысл пересмотреть, КАК происходит тестирование в старых тест-комплектах: может быть, некоторые из тест-кейсов уже устарели и/или были написаны тулы для упрощения работы некоторых из них и пр.
278 |
Тестирование Дот Ком. Часть 3 |
|
в. Когда денег много, а ума мало, прибегают к массированному наймуновых тестировщиков, что, конечно, лишь отодвинет реше ние проблемы, но не решит ее, так как нельзя бесконечно нани мать людей. Я против массированного найма (иногда нанимаются десятки!!! тестировщиков в год) и считаю, чтоинтернет-компании нужен департамент качества, состоящий из немногочисленной группы профессиональных высокооплачиваемых специалистов, которые будут решать проблему регрессивного тестирования подходами а, б и г.
г. Автоматизации регрессивного тестирования посвящено мно жество монографий. Я же просто введу вас в курс дела.
Итак, в проекте www.testshop.rs скопилось, например, 78 тесткомплектов, которые нужно как-то исполнять при регрессивном тестировании, причем это количество постоянно увеличивается. Так как у нас нет спеца по автоматизации тестирования, то мы такого спеца нанимаем. Например, это будет г-н Говорков. Созывается совещание тестировщиков, и менеджер представляет г-на Говоркова в роли, примерно, мессии, который решит все наши проблемы с регрессивным тестированием. Когда слово предоставляется самому г-ну Говоркову, то его речь сводится к следующему: "Ща я вам тут все заавтоматизирую!" Тратится несколько тысяч (нередко десятки тысяч) долларов на покупку программы для автоматизации тестирования Silk Test (производитель — компания Segue), и автоматизация начинается.
Через неделю происходит первая демонстрация: запускается автоматический скрипт и начинается магия:
подпрограмма силк-теста — агент открывает окно браузера, вводит имя пользователя и пароль, нажимает на кнопку "Вход ", совершает покупку и оплату и сравнивает фактический результат с ожидаемым. Все в полном восторге, ведь очевидно, что через пару месяцев все тест-комплекты будут автоматизированы и, вместо того чтобы работать в поте лица в выходные, мы просто запускаем в пятницу автоматический скрипт силктеста, а в понедельник видим результат исполнения каждого автоматизированного тест-кейса. Одним словом —лепота!
Однако когда во время регрессивного тестирования следующего релиза мы просим г-на Говоркова запустить автоматические скрипты для тест-комплектов, которые он уже "заавтоматизироват", выясняется, что его автоскрипты не работают из-за того, что ин- терфейсвеб-сайтабылвнесколькихместахнезначительноизменен.