Читайте также:
|
Так, если сайт рушится (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 | Нарушение авторских прав