Читайте также:
|
|
• после занесения бага е-мейл посылается
автору бага и держателю бага,
• а при изменении записи о баге —
автору бага, держателю бага и лицу, изменившему баг.
Настройками оповещения, общими для всех участников процесса, ведает, как вы уже догадались, администратор СТБ.
Таким образом, атрибут "Список для оповещения" используется автором бага либо другим заинтересованным лицом для того, чтобы е-мейлы посылались тем, кто не является реципиентом по умолчанию.
Я всегда включаю в "Список для оповещения" имя продюсера, чтобы тот знал о состоянии дел, связанных с тестированием его спека.
Выбор значений для данного атрибута не является обязательным.
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 request", но уже с приоритетом ПЗ.
Вот такие дела...
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; просмотров: 98 | Нарушение авторских прав