Серьезность — это категория абсолютная. Приоритет — это категория относительная.
Так, если сайт рушится (crash), то это С1, и мы не можем, например, по политическим соображениям изменить серьезность такого бага, например, на С2, так как ситуация (с системным сбоем) четко соответствует дефиниции С1. Если же тести-ровщик назначил приоритет как П1, то программист вполне
Жизнь замечательных багов
229
может оспорить такое решение и в итоге приоритет будет П2. Таким образом, назначение серьезности — это механическое действие, а приоритета — творческое, связанное с оценкой угрозы бага для бизнеса компании.
Часто в документации процесса и настройках СТБ определена четкая связь между верхними значениями серьезности и приоритета.
Например, если установлено, что "при серьезности С1 значение приоритета должно быть П1", и тестировшик выбирает С1 и П2, то СТБ не позволит занести баг и выдаст ошибку.
В большинстве же случаев, т.е. при СЗ (функциональных) багах, нет четкой зависимости между серьезностью и приоритетом, и в "Описании и шагах..." иногда стоит объяснить, почему вы выбрали именно этот приоритет, а не более высокий или более низкий.
Кстати, П1 — баг, из-за которого может сорваться запланированный релиз, называется showstopper ("пробка"). Примером такого бага может служить ситуация, когда тестирование функциональности "Оплата" полностью заблокировано из-за бага во вспомогательном ПО, симулирующем платежную систему.
Еще пара слов о связи серьезности и приоритета бага: например, мы имеем дело с судопроизводством, а не интернет-проектом. Фраза "казнить нельзя помиловать"содержит баг, так как отсутствует запятая. Отсутствие запятой — это С4, но ситуация, когда может быть наказан невиновный или оправдан преступник, — это П1. Ну, например, из-за величины негативных последствий для имиджа правосудия (шутка).
|
|
|
Кроме привязки к серьезности бага на приоритет могут воздействовать следующие потенциальные либо реальные вещи:
• процент затронутых пользователей,
• денежные потери для компании,
• негативные юридические последствия для компании,
• негативные последствия для имиджа компании.
В каждой компании должны быть дефиниции приоритета багов (bug priority definitions), в которых обязательным элементом является указание сроков для починки багов (дополнительным элементом могут быть факторы, указанные выше, например процент затронутых пользователей).
230
Тестирование Дот Ком. Часть 3
Вот простейший пример дефиниций.
| Приоритет бага | Дефиниция |
| П1 | Брось все дела и зафиксируй баг |
| П2 | Зафиксируй баг в течение 72 часов |
| ПЗ | Зафиксируй баг до завершения тестирования данного основного релиза |
| П4 | Зафиксируй, если возможно |
Примеры
|
|
|
П1 —П2 — все понятно.
ПЗ — каждая стадия цикла разработки ПО имеет свои запланированные временные рамки. Таким образом, если релиз должен состояться 16 марта, то до 16 марта все ПЗ должны быть зафиксированы и закрыты.
П4 — такие баги фиксируются, если у программиста есть время. Например, в какой-нибудь старой версии браузера интернет/эксплорер (Internet Explorer — IE) не работает какое-нибудь суперзамысловатое флоу, которое вряд ли может прийти кому-либо в голову.
У каждой компании есть свои заморочки, но, как правило, все баги П1, П2 и ПЗ должны быть зафиксированы и закрыты до релиза.
В случае с ПЗ, если не хватает времени, может приниматься решение о релизе, содержащем баг, с условием, что в течение такого-то периода времени (дни) этот баг будет зафиксирован, протестирован и патч-релиз выпущен на машину для пользователей.
Почему принимается такое решение, которое, казалось бы, противоречит здравому смыслу?
Очень просто. Политика, господа: акционеры компании ждут доходов от своих инвестиций, и каждый основной либо дополнительный релиз — это потенциальный катализатор новых прибылей, и такие вещи, как парочка незафиксированных ПЗ, в мире чистогана в расчет не принимаются.
|
|
|
Кроме того, менеджменту придется держать ответ перед теми же акционерами, почему релиз не был выпущен вовремя.
Иногда опять же по политическим соображениям принимается решение о понижении приоритета бага со всеми вытекающими отсюда последствиями, например, когда П2 понижается до ПЗ и этот ПЗ выпускается на продакшн.
Приоритет обязательно должен быть выбран из списка, иначе баг нельзя занести в СТБ.
В случае сомнений в том, какой приоритет поставить, например ПЗ или П2, я обычно иду по пути повышения приоритета, т.е. выбираю П2. Как говорится, не корысти ради, а во благо наших дорогих и любимых пользователей.
Жизнь замечательных багов
231
Иногда возникают конфликтные ситуации, когда программист считает, что приоритет завышен, а тестировщик утверждает, что "сам ты такой" и приоритет назначен правильно. В таком случае вы можете попросить своего менеджера принять решение о снижении приоритета, если вы считаете, что поставленный вами приоритет верен и не хотите снижать его сами. Помните, что дружба дружбой, а если вы были заблокированы и из-за любви к своему программисту поставили ПЗ вместо Ш, то проблемы с невыполнением плана будут у вас, а не у него, так как это вы, а не он можете не закончить в срок исполнение тестирования.
|
|
|
Приоритет — это мощнейший инструмент, используя который вы влияете на расписание работы программиста, поэтому не злоупотребляйте им (приоритетом) и используйте его мудро.
NOTIFY LIST (СПИСОК ДЛЯ ОПОВЕЩЕНИЯ)
Это ниспадающее меню со списком алиасов всех пользователей, зарегистрированных в СТБ. Во многих случаях тестировщику необходимо, чтобы
• о факте занесения бага и
• о любом изменении в самой записи о баге
знал определенный круг людей.
Оповещение происходит с помощью е-мейла, в который включаются:
• номер бага;
• статус;
• краткое описание;
• приоритет;
• серьезность бага;
• название, старое и новое значение измененного атрибута (например, кто-то занес свое мнение в комментарий);
• имя того, кто покусился изменить баг (либо занести новый баг в СТБ).
Кстати,
каждый пользователь СТБ может отрегулировать настройки оповещения как ему удобно, например, можно сделать так, чтобы е-мейл посылался каждый раз, когда заносится баг, упоминающий в кратком описании некий спек, например, за номером 7611.
232
Тестирование Дот Ком. Часть 3
Как правило, по умолчанию
• после занесения бага е-мейл посылается
автору бага и держателю бага,
• а при изменении записи о баге —
автору бага, держателю бага и лицу, изменившему баг.
Настройками оповещения, общими для всех участников процесса, ведает, как вы уже догадались, администратор СТБ.
Таким образом, атрибут "Список для оповещения" используется автором бага либо другим заинтересованным лицом для того, чтобы е-мейлы посылались тем, кто не является реципиентом по умолчанию.
Я всегда включаю в "Список для оповещения" имя продюсера, чтобы тот знал о состоянии дел, связанных с тестированием его спека.
Выбор значений для данного атрибута не является обязательным.
CHANGE HISTORY (ИСТОРИЯ ИЗМЕНЕНИЙ)
Это наиважнейший, автоматически заполняемый атрибут. Суть его в том, что любоеизменение бага отражается в нередактируе-мом многострочном текстовом поле в следующем формате:
• дата и время изменения (date and time of change);
• имя лица, изменившего баг (who changed);
• название измененного атрибута (what was changed);
• предыдущее значение атрибута (previous value);
• новое значение атрибута (new value).
Запомните, что любые действия любого лица,имеющего счет в СТБ, автоматически записываются,запись доступна для всех пользователей СТБ и не подлежит редактированию. Таким образом, можно до секунды увидеть, что конкретно, как конкретно и кем конкретно было изменено. Анонимность, столь любимая посетителями интернет-форумов, полностью исключена.
Жизнь замечательных багов
233
TYPE (ТИП БАГА)
Это ниспадающее меню со значениями:
• bug (баг),
• feature request (запрос о фича).
По умолчанию значение типа бага (типа записи) — это "баг", т.е. расхождение между фактическим и ожидаемым результатом, и 95% багов (записей) в СТБ имеет значение "баг".
Компьютерный термин "Feature " не имеет эквивалентного термина в русском языке, и мы можем
• либо изобрести новое слово,
• либо позаимствовать существующее слово из английского языка и соответственно писать его русскими буквами (что мы и сделаем).
Я всегда стараюсь найти подходящий перевод английской терминологии, но иногда это просто не удается, и хотя заимствованные слова, написанные кириллицей, могут поначачу коробить слух и глаз, это вещь вполне легитимная. Например, книга Василия Аксенова "В поисках грустного бэби" изобилует такими словами, так как многие из них просто невозможно правильно перевести (например, "плаза "). Кроме того, есть термины, устоявшиеся в профессиональной среде (например, наша "фича ").
Итак, фича— это в зависимости от контекста
• функциональность либо
• характеристика (или свойство) компонента кода, интерфейса, базы данных и пр.
Например
Значение "функциональность" работает, если мы говорим о кепча. Значение "характеристика" работает, если мы говорим об оптимизации кода с целью улучшения перформанса (скорости работы сайта).
Обратно кFeature request.
Баг с типом Feature request заносится в СТБ с именем продюсера или программиста в Assigned to, когда у вас родилась идея об улучшении некой существующей фича или о новой фича.
Значение типа Feature request также используется в баге, служащем основанием для патч-релиза, в случае, когда появилась не-
234
Тестирование Дот Ком. Часть 3
обходимость в срочном изменениикода на машине для пользователей и это изменение не связано с багом (как отклонением фактического от ожидаемого).
Логичным будет вопрос:почему мы употребили выражение "срочное изменение"?
Вот ответ:если нужна новая функциональность, то продюсер пишет спек, программист его кодирует и т.д. в соответствии с процессом разработки ПО. Каждая стадия процесса имеет свои временные рамки, которые привязаны к расписанию релизов (release schedule). А что, если у нас появилась незапланированная потребность в новой фича и ее нужно срочно выпустить?
Пример
Допустим, мы выпускаем один основной релиз в месяц. Сегодня 10 ноября, и последний основной релиз (7.0) состоялся 31октября. Если сегодня (Ю ноября) появилась новая идея (например, о добавлении кепча на страницу регистрации), то если мы включим ее в наш процесс разработки как любую очередную идею, то наша многострадальная кепча появится на машине для пользователей не 1 декабря в релизе 8.0 (так как все спеки релиза 8.0 уже заморожены), а 1января в релизе 9.0. Таким образом, придется ждать больше полутора месяцев. Что делать, если у нас нет полутора месяцев, а есть полтора часа ? Нужно занести баг "Feature request" с приоритетом П1. Если же фича может подождать до 8.0, то опять же заносим баг с типом "Feature request", но уже с приоритетом ПЗ.
Вот такие дела...
STATUS (СТАТУС)
Это ниспадающее меню со значениями:
• Open (Открыт),
• Closed (Закрыт),
• Re-Open (Повторно открыт).
Значение Open присваивается багу автоматически при занесении бага.
Закрыть баг можно только при соответствующей резолюции (об этом через минуту).
Значение Re-Open выбирается тестировщиком, когда он возрождает к жизни закрытый баг.
Почему возникают ситуации, когда баги приходится открывать заново?
Жизнь замечательных багов
235
Например
• программист сделал изменение в коде и поломал отремонтированный ранее код, так что проблема появилась заново. В этом случае говорят о том, что баг был reintroduced ("заново внесен на рассмотрение" — так себе перевод, но ничего лучше я не нашел);
• баг был найден на машине для пользователей. Программист сделал checkin отремонтированного кода в бранч-версии машины для пользователей и позабыл сделать checkin в ствол. Следовательно, в следующем релизе баг появляется снова.
В связи со статусом запомним две вещи:
• ВСЕ найденные баги должны заноситься в СТБ.Исключений быть не может. Ваша работа как тестировщика — искать баги. Единственный и неповторимый результат вашей работы — баг, занесенный в СТБ. Умные программисты никогда на вас не обидятся, так как качество их работы измеряется не количеством багов, ими допущенных, а скоростью, с которой они эти баги чинят (почти по Глебу Жеглову);
• занесенные в СТБ баги НИКОГДА не удаляются из СТБ.
Чтобы ни случилось, пока живет компания, ее СТБ включает ВСЕ баги, найденные в продукте. Администратор СТБ должен настроить последнюю так, чтобы исключить возможность удаления багов пользователями СТБ.
Таким образом, каждый баг, когда-либо найденный в продукте, будет иметь одно из трех упомянутых значений статуса.
RESOLUTION (РЕЗОЛЮЦИЯ)
Это ниспадающее меню со значениями:
Not Assigned (не приписан)
Assigned (приписан)
Fix in Progress (баг ремонтируется)
Fixed (баг отремонтирован)
Build in Progress (билд на тест-машину в процессе)
Verify (проведи регрессивное тестирование)
Fix is Verified (ремонт был успешен)
Verification Failed (ремонт был неуспешен)
Can't Reproduce (не могу воспроизвести)
Duplicate (дубликат)
Not a bug(не баг)
3rd party bug (не наш баг)
No longer applicable (поезд ушел)
236
Тестирование Дот Ком. Часть 3
Резолюция — очень важный атрибут, напрямую связанный со статусом.
Если статус — это своего рода "жив", "умер", "реинкарнировался", то резолюция — это "поступил в институт", "женился", "купил машину", т.е. резолюция — это детализация статуса.
Not Assigned (не приписан)
Такая резолюция может быть после того, как баг занесен, но лицо, занесшее баг в СТБ, не знает, кто может этот баг зафиксировать.
Assigned (приписан)
К новому багу приписан держатель (owner), т.е. лицо, ответственное за совершение следующего действия в отношении бага в соответствии с процессом.
Как мы помним, у каждого открытого бага всегда есть держатель.
В случае резолюции Not Assigned держателем бага является автор бага, не передавший его дальше.
Итак, меняем статус на Assigned, когда передаем баг для ремонта, и выбираем имя из ниспадающего меню Assigned to.
Fix in Progress (баг ремонтируется)
Это значение резолюции выбирается программистом, когда он начинает ремонт бага. Держатель бага — программист.
Fixed (баг отремонтирован)
Это значение резолюции выбирается программистом после того, как он
• отремонтировал баг и
• сохранил код в CVS.
Держатель бага — релиз-инженер.
Build in Progress (билд на тест-машину в процессе)
Это значение резолюции выбирается релиз-инженером (а иногда и билд-скриптом) после запуска на тест-машину билда с отремонтированным кодом, т.е. Build in Progress приходит на смену Fixed.
Жизнь замечательных багов
237
Здесь нужно заметить, что если даже баг найден на машине для пользователей, патч-релиз происходит только после того, как ремонт протестирован на тест-машине.
Держатель бага — релиз-инженер.
Verify (проведи регрессивное тестирование)
Это значение резолюции выбирается релиз-инженером (а иногда и билд-скриптом) после того, как билд на тест-машину завершен.
Держатель бага — лицо, чье имя указано в Verifier. Если у вери-фаера нет возможности проверить ремонт, то он может просто выбрать другое значение Verifier так, чтобы его коллега принял груз ответственности.
Fix is Verified (ремонт был успешен)
Регрессивное тестирования бага состоит из двух частей, следующих одна за другой в таком порядке:
Часть 1:
проверка того, что баг был действительно починен,т.е. четко следуем инструкциям из "Описания и шагов..." для воспроизведения бага. Если функциональность работает как следует, то баг действительно был починен.
Часть 2:
Дата добавления: 2018-05-02; просмотров: 994; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!