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

Савин Роман

230

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

Вот простейший пример дефиниций.

Приоритет бага

Дефиниция

П1

Брось все дела и зафиксируй баг

П2

Зафиксируй баг в течение 72 часов

ПЗ

Зафиксируй баг до завершения тестирования данного

основного релиза

П4

Зафиксируй,

если возможно

Примеры

П1 —П2 — все понятно.

ПЗ — каждая стадия цикла разработки ПО имеет свои запланирован-

ные временные рамки. Таким образом, если релиз должен состояться

16 марта, то до 16 марта все ПЗ должны быть зафиксированы и закрыты.

П4 — такие баги фиксируются, если у программиста есть время. На-

пример, в какой-нибудь старой версии браузера интернет/эксплорер

(Internet Explorer — IE) не работает какое-нибудь суперзамысловатое

флоу, которое вряд ли может прийти кому-либо в голову.

У каждой компании есть свои заморочки, но, как правило, все баги П1,

П2 и ПЗ должны быть зафиксированы и закрыты до релиза.

В случае с ПЗ, если не хватает времени, может приниматься решение о

релизе, содержащем баг, с условием, что в течение такого-то периода

времени (дни) этот баг будет зафиксирован, протестирован и патч-

релиз выпущен на машину для пользователей.

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

речит здравому смыслу?

Очень просто. Политика, господа: акционеры компании ждут доходов

от своих инвестиций, и каждый основной либо дополнительный релиз —

это потенциальный катализатор новых прибылей, и такие вещи, как пароч-

ка незафиксированных ПЗ, в мире чистогана в расчет не принимаются.

Кроме того, менеджменту придется держать ответ перед теми же акцио-

нерами, почему релиз не был выпущен вовремя.

Иногда опять же по политическим

соображениям принимается реше-

ние о понижении приоритета бага со всеми вытекающими отсюда по-

следствиями, например, когда П2 понижается до ПЗ и этот ПЗ выпус-

кается на продакшн.

Приоритет обязательно должен быть выбран из списка, иначе баг

нельзя занести в СТБ.

В случае сомнений в том, какой приоритет поставить, например

ПЗ или П2, я обычно иду по пути повышения приоритета, т.е.

выбираю П2. Как говорится, не корысти ради, а во благо наших

дорогих и любимых пользователей.

Жизнь замечательных багов

231

Иногда возникают конфликтные ситуации, когда программист

считает, что приоритет завышен, а тестировщик утверждает, что

"сам ты такой" и приоритет назначен правильно. В таком случае

вы можете попросить своего менеджера принять решение о сни-

жении приоритета, если вы считаете, что поставленный вами

приоритет верен и не хотите снижать его сами. Помните, что

дружба дружбой, а если вы были заблокированы и из-за люб-

ви к своему программисту поставили ПЗ вместо Ш, то про-

блемы с невыполнением плана будут у вас, а не у него, так

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

тестирования.

Приоритет — это мощнейший инструмент, используя который вы

влияете на расписание работы программиста, поэтому не зло-

употребляйте им (приоритетом) и используйте его мудро.

NOTIFY LIST (СПИСОК ДЛЯ ОПОВЕЩЕНИЯ)

Это ниспадающее меню со списком алиасов всех пользователей,

зарегистрированных в СТБ. Во многих случаях тестировщику не-

обходимо, чтобы

• о факте занесения бага и

• о любом изменении в самой записи о баге

знал определенный круг людей.

Оповещение происходит с помощью е-мейла, в который вклю-

чаются:

• номер бага;

• статус;

• краткое описание;

• приоритет;

• серьезность бага;

• название, старое и новое значение измененного атрибута

(например, кто-то занес свое мнение в комментарий);

• имя того, кто покусился изменить баг (либо занести новый

баг в СТБ).

Кстати,

каждый пользователь СТБ может отрегулировать настройки оповеще-

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