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

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

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

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

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

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

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

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

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

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 также используется в баге, служа­щем основанием для патч-релиза, в случае, когда появилась не-

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

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

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

Вот ответ: если нужна новая функциональность, то продюсер пишет спек, программист его кодирует и т.д. в соответствии с про­цессом разработки ПО. Каждая стадия процесса имеет свои вре­менные рамки, которые привязаны к расписанию релизов (release schedule). А что, если у нас появилась незапланированная потреб­ность в новой фича и ее нужно срочно выпустить?

Пример

Допустим, мы выпускаем один основной релиз в месяц. Сегодня 10 ноября, и последний основной релиз (7.0) состоялся 31 октября. Если сегодня (Ю ноября) появилась новая идея (например, о добавле­нии кепча на страницу регистрации), то если мы включим ее в наш процесс разработки как любую очередную идею, то наша многостра­дальная кепча появится на машине для пользователей не 1 декабря в релизе 8.0 (так как все спеки релиза 8.0 уже заморожены), а 1 января в релизе 9.0. Таким образом, придется ждать больше полутора меся­цев. Что делать, если у нас нет полутора месяцев, а есть полтора часа? Нужно занести баг "Feature request" с приоритетом П1. Если же фича может подождать до 8.0, то опять же заносим баг с типом "Feature re­quest", но уже с приоритетом ПЗ.

Вот такие дела...

STATUS (СТАТУС)

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

• Open (Открыт),

• Closed (Закрыт),

• Re-Open (Повторно открыт).

Значение Open присваивается багу автоматически при занесении бага.

Закрыть баг можно только при соответствующей резолюции (об этом через минуту).

Значение Re-Open выбирается тестировщиком, когда он возрож­дает к жизни закрытый баг.

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

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

Например

• программист сделал изменение в коде и поломал отремонтиро­ванный ранее код, так что проблема появилась заново. В этом слу­чае говорят о том, что баг был 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 (поезд ушел)

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

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

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

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

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

Assigned (приписан)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здесь нужно заметить, что если даже баг найден на машине для пользователей, патч-релиз происходит только после того, как ре­монт протестирован на тест-машине.

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

Verify (проведи регрессивное тестирование)

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

Держатель бага — лицо, чье имя указано в Verifier. Если у вери-фаера нет возможности проверить ремонт, то он может просто выбрать другое значение Verifier так, чтобы его коллега принял груз ответственности.

Fix is Verified (ремонт был успешен)

Регрессивное тестирования бага состоит из двух частей, следую­щих одна за другой в таком порядке:

Часть 1:

проверка того, что баг был действительно починен, т.е. четко следуем инструкциям из "Описания и шагов..." для вос­произведения бага. Если функциональность работает как сле­дует, то баг действительно был починен.

Часть 2:

Дата добавления: 2015-12-07