testirovanie_dot-com

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры

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

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

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

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

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

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

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

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

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

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

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

Как правило, по умолчанию

•после занесения бага е-мейл посылается

автору бага и держателю бага,

•а при изменении записи о баге —

автору бага, держателю бага и лицу, изменившему баг.

Настройками оповещения, общими для всех участников процесса, ведает, как вы уже догадались, администратор СТБ.

Таким образом, атрибут "Список для оповещения" используется автором бага либо другим заинтересованным лицом для того, чтобы е-мейлы посылались тем, кто не является реципиентом

по умолчанию.

Я всегда включаю в "Список для оповещения" имя продюсера, чтобы тот знал о состоянии дел, связанных с тестированием его спека.

Выбор значений для данного атрибута не является обязательным.

CHANGE HISTORY (ИСТОРИЯ ИЗМЕНЕНИЙ)

Это наиважнейший, автоматически заполняемый атрибут. Суть его в том, что любое изменение бага отражается в нередактируемом многострочном текстовом поле в следующем формате:

•дата и время изменения (date and time of change);

•имя лица, изменившего баг (who changed);

•название измененного атрибута (what was changed);

•предыдущее значение атрибута (previous value);

•новое значение атрибута (new value).

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

TYPE (ТИП БАГА)

Это ниспадающее меню со значениями:

•bug (баг),

•feature request (запрос о фича).

По умолчанию значение типа бага (типа записи) — это "баг", т.е. расхождение между фактическим и ожидаемым результатом, и 95% багов (записей) в СТБ имеет значение "баг".

Компьютерный термин "Feature " не имеет эквивалентного термина в русском языке, и мы можем

•либо изобрести новое слово,

•либо позаимствовать существующее слово из английского языка и соответственно писать его русскими буквами (что мы и сделаем).

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

Итак, фича — это в зависимости от контекста

•функциональность либо

•характеристика (или свойство) компонента кода, интерфейса, базы данных и пр.

Например

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

Обратнок Feature request.

Баг с типом Feature request заносится в СТБ с именем продюсера или программиста в Assigned to, когда у вас родилась идея об улучшении некой существующей фича или о новой фича.

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

обходимость в срочном изменении кода на машине для пользователей и это изменение не связано с багом (как отклонением фактического от ожидаемого).

Логичным будет вопрос: почему мы употребили выражение

"срочное изменение"?

Вот ответ: если нужна новая функциональность, то продюсер пишет спек, программист его кодирует и т.д. в соответствии с процессом разработки ПО. Каждая стадия процесса имеет свои временные рамки, которые привязаны к расписанию релизов (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 выбирается тестировщиком, когда он возрождает к жизни закрытый баг.

Почему возникают ситуации, когда баги приходится открывать заново?

Резолюция — очень важный атрибут, напрямую связанный со статусом.

Если статус — это своего рода "жив", "умер", "реинкарнировался", то резолюция — это "поступил в институт", "женился", "купил машину", т.е. резолюция — это детализация статуса.

Not Assigned (не приписан)

Такая резолюция может быть после того, как баг занесен, но лицо, занесшее баг в СТБ, не знает, кто может этот баг зафиксировать.

Assigned (приписан)

К новому багу приписан держатель (owner), т.е. лицо, ответственное за совершение следующего действия в отношении бага в соответствии с процессом.

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

жатель.

В случае резолюции Not Assigned держателем бага является автор бага, не передавший его дальше.

Итак, меняем статус на Assigned, когда передаем баг для ремонта, и выбираем имя из ниспадающего меню Assigned to.

Fix in Progress (баг ремонтируется)

Это значение резолюции выбирается программистом, когда он начинает ремонт бага. Держатель бага — программист.

Fixed (баг отремонтирован)

Это значение резолюции выбирается программистом после того, как он

•отремонтировал баг и

•сохранил код в CVS.

Держатель бага — релиз-инженер.

Build in Progress (билд на тест-машину в процессе)

Это значение резолюции выбирается релиз-инженером (а иногда и билд-скриптом) после запуска на тест-машину билда с отремонтированным кодом, т.е. Build in Progress приходит на смену

Fixed.

Такимтестоммыпроверяем,чтофлоу,вкотороевключенотремонтированный компонент, все еще работает.

Изменить резолюцию на Fix is Verified можно непосредственно после успешного завершения части 1.

При значении Fix is Verified можно закрыть баг. После закрытия бага у него нет держателя, так как его некуда больше передавать.

После того как резолюция стала Fix is Verified и до закрытия бага держателем бага является товарищ, который выбралэтурезолюцию.

Verification Failed (ремонт был неуспешен)

Если первая часть регрессивного тестирования показала неуспешность ремонта, т.е. баг все еще существует в коде, то мы не делаем второй части, а просто выбираем это значение резолюции, после чего держателем бага становится программист, который починил код.

Can Ч Reproduce (не могу воспроизвести)

Эта неприятная для тестировщика резолюция выбирается программистом после того, как перед починкой кода он пытается воспроизвести проблему и не может сделать этого. Как правило, Can 7 Reproduce имеет место в следующих случаях:

•"Описание и шаги..." содержат неполную, неверную или нечеткую информацию о том, как воспроизвести баг, и/или

•бага нет, т.е. тестировщик принял за баг правильно работающий код.

Одной из основных вещей в отношении багов в ПО является идея об их воспроизводимости, т.е. если баг существует, его можно воспроизвести. Бывает так, что тестировщик, найдя баг в ПО, сразу же открывает СТБ, заносит новый баг и, довольный собой, продолжает работу. Программист же соответственно бросает работу, начинает воспроизводить этот баг и после нескольких неудачных попыток посылает его обратно тестировщику с резолюцией Can't Reproduce. Особенно неприятна ситуация, когда описание бага содержит сложную и долгую процедуру, необходимую для воспроизведения.

Лучшим средством превентирования подобных вещей является правило: "Перед тем как занести новый баг, воспроизведи его еще раз", т.е., после того как найден баг, необходимо воспроиз-