Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Серьезность — это категория абсолютная. Приоритет — это категория относительная.

Читайте также:
  1. I. Категория: научные работы
  2. VI. Определение приоритетов в СУПер.
  3. Анализ рабочей силы по категориям занятых
  4. Аналитическая записка о коллизии конституционных положений о суверенитете и приоритетности общепризнанных принципов и норм международного права.
  5. Весовая категория 50 кг
  6. Весовая категория 54 кг
  7. Весовая категория 63 кг

Так, если сайт рушится (crash), то это С1, и мы не можем, на­пример, по политическим соображениям изменить серьезность такого бага, например, на С2, так как ситуация (с системным сбоем) четко соответствует дефиниции С1. Если же тести-ровщик назначил приоритет как П1, то программист вполне


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



может оспорить такое решение и в итоге приоритет будет П2. Таким образом, назначение серьезностиэто механическое дей­ствие, а приоритетатворческое, связанное с оценкой угрозы бага для бизнеса компании.

Часто в документации процесса и настройках СТБ определена четкая связь между верхними значениями серьезности и приори­тета.

Например, если установлено, что "при серьезности С1 значение при­оритета должно быть П1", и тестировшик выбирает С1 и П2, то СТБ не позволит занести баг и выдаст ошибку.

В большинстве же случаев, т.е. при СЗ (функциональных) багах, нет четкой зависимости между серьезностью и приоритетом, и в "Описании и шагах..." иногда стоит объяснить, почему вы выбрали именно этот приоритет, а не более высокий или более низкий.

Кстати, П1баг, из-за которого может сорваться запланированный релиз, называется showstopper ("пробка"). Примером такого бага мо­жет служить ситуация, когда тестирование функциональности "Оплата" полностью заблокировано из-за бага во вспомогательном ПО, симули­рующем платежную систему.

Еще пара слов о связи серьезности и приоритета бага: например, мы имеем дело с судопроизводством, а не интернет-проектом. Фраза "казнить нельзя помиловать" содержит баг, так как от­сутствует запятая. Отсутствие запятой — это С4, но ситуация, когда может быть наказан невиновный или оправдан преступник, — это П1. Ну, например, из-за величины негативных последствий для имиджа правосудия (шутка).

Кроме привязки к серьезности бага на приоритет могут воздейст­вовать следующие потенциальные либо реальные вещи:

• процент затронутых пользователей,

• денежные потери для компании,

• негативные юридические последствия для компании,

• негативные последствия для имиджа компании.

В каждой компании должны быть дефиниции приоритета багов (bug priority definitions), в которых обязательным элементом яв­ляется указание сроков для починки багов (дополнительным эле­ментом могут быть факторы, указанные выше, например процент затронутых пользователей).



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


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

 

Приоритет бага Дефиниция
П1 Брось все дела и зафиксируй баг
П2 Зафиксируй баг в течение 72 часов
ПЗ Зафиксируй баг до завершения тестирования данного основного релиза
П4 Зафиксируй, если возможно

Примеры

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

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

П4 — такие баги фиксируются, если у программиста есть время. На­пример, в какой-нибудь старой версии браузера интернет/эксплорер (Internet Explorer — IE) не работает какое-нибудь суперзамысловатое флоу, которое вряд ли может прийти кому-либо в голову.

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

В случае с ПЗ, если не хватает времени, может приниматься решение о релизе, содержащем баг, с условием, что в течение такого-то периода времени (дни) этот баг будет зафиксирован, протестирован и патч-релиз выпущен на машину для пользователей.

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

Очень просто. Политика, господа: акционеры компании ждут доходов от своих инвестиций, и каждый основной либо дополнительный релиз — это потенциальный катализатор новых прибылей, и такие вещи, как пароч­ка незафиксированных ПЗ, в мире чистогана в расчет не принимаются.

Кроме того, менеджменту придется держать ответ перед теми же акцио­нерами, почему релиз не был выпущен вовремя.

Иногда опять же по политическим соображениям принимается реше­ние о понижении приоритета бага со всеми вытекающими отсюда по­следствиями, например, когда П2 понижается до ПЗ и этот ПЗ выпус­кается на продакшн.

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

В случае сомнений в том, какой приоритет поставить, например ПЗ или П2, я обычно иду по пути повышения приоритета, т.е. выбираю П2. Как говорится, не корысти ради, а во благо наших дорогих и любимых пользователей.


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



Иногда возникают конфликтные ситуации, когда программист считает, что приоритет завышен, а тестировщик утверждает, что "сам ты такой" и приоритет назначен правильно. В таком случае вы можете попросить своего менеджера принять решение о сни­жении приоритета, если вы считаете, что поставленный вами приоритет верен и не хотите снижать его сами. Помните, что дружба дружбой, а если вы были заблокированы и из-за люб­ви к своему программисту поставили ПЗ вместо П1Ш, то про­блемы с невыполнением плана будут у вас, а не у него, так как это вы, а не он можете не закончить в срок исполнение тестирования.

Приоритет — это мощнейший инструмент, используя который вы влияете на расписание работы программиста, поэтому не зло­употребляйте им (приоритетом) и используйте его мудро.

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

Это ниспадающее меню со списком алиасов всех пользователей, зарегистрированных в СТБ. Во многих случаях тестировщику не­обходимо, чтобы

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

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

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

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

• номер бага;

• статус;

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

• приоритет;

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

• название, старое и новое значение измененного атрибута (например, кто-то занес свое мнение в комментарий);

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

Кстати,

каждый пользователь СТБ может отрегулировать настройки оповеще­ния как ему удобно, например, можно сделать так, чтобы е-мейл посы­лался каждый раз, когда заносится баг, упоминающий в кратком опи­сании некий спек, например, за номером 7611.



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


Дата добавления: 2015-12-07; просмотров: 314 | Нарушение авторских прав



mybiblioteka.su - 2015-2024 год. (0.01 сек.)