tестирование dot com
Шрифт:
то я сразу же заношу его в СТБ. Если же я вижу проблему, которая
не связана с моим ожидаемым результатом и/или функциональ-
ностью, о которой я имею полную информацию, то обычно контак-
тирую с коллегами-тестировщиками, которые владеют вопросом
о функциональности, в которой, как мне кажется, есть баг.
Резолюция No longer applicable позволяет закрыть баг, если он на
самом деле больше не баг.
Процесс
Теперь, после того как мы поговорили об атрибутах СТБ, посмот-
рим на блок-схему. На ней мы воочию видим основу процесса
трэкинга багов. Эта основа сама по себе является стандартной
версией процесса, и интернет-компании используют ее в таком
либо измененном виде.
246
Тестирование Дот Ком. Часть 3
Процесс трэкинга багов
Жизнь замечательных багов
247
Кстати, для упрощения допустим, что баг заносится тестиров-
щиком (хотя мы знаем, что баг может заноситься кем угодно)
и против кода программиста (хотя мы знаем, что существуют
и баги спека, которые заносятся против продюсера).
Давайте сделаем так:
• сначала рассмотрим процесс концептуально, затем
• привяжем к каждой его стадии наши атрибуты (детальное
рассмотрение процесса), затем
• приведем конкретный пример.
Концептуальное рассмотрение процесса трэкинга багов
Задача 1: После того как мы нашли проблему в ПО, заносим новый
баг.
Задача 2: Программист получает баг, старается понять, в чем про-
блема, и если это действительно баг, то
Задача 3: Программист начинает ремонт.
Задача 4: После того как ремонт закончен, программист
должен сделать checkin кода в CVS.
Задача 5: Релиз-инженер запускает новый билд, чтобы от-
ремонтированный код пришел из CVS на тест-ма-
шину.
Задача 6: Тестировщик проводит регрессивное тестирова-
ние, и если починка НЕ удалась, то
Задача 7: Баг возвращается программисту на но-
вый ремонт.
Если же починка удалась, то
Задача 8: Баг закрывается. Goodbye my love, Goodbye.
Идем обратно к развилке после задачи 2. Допустим, программист
не считает, что зарапортованная ситуация является
Задача 9: Возвращает баг.
Задача 10: Тестировщик старается понять свою ошибку, и
если ошибка имела место и баг соответственно
места не имел, то
Задача 8: Баг закрывается.
Если же тестировщик считает, что это все-таки баг, то
баг отправляется обратно программисту.
Задача 2: Программист снова пытается понять, баг ли это. И т.д.
248
Тестирование Дот Ком. Часть 3
Детальное рассмотрение процесса
Давайте вольем в рассмотренную форму содержимое, состоящее
из атрибутов и их значений, как мы хотим это нашей компании
www.testshop.rs.
Задача 1:
Атрибут
Комментарий по заполнению либо
конкретное(ые) значение(я) атрибута
Summary
Краткое описание
Description and Steps
Описание и шаги...
to Reproduce
Attachment
Используем это поле, если нужна дополнительная
иллюстрация
Assigned to
Имя программиста
Component
Название компонента
Found on
Где был найден баг
Version Found
Номер версии
Build Found
Номер билда
Severity
Значение серьезности
Priority
Значение приоритета
Notify list
По минимуму — имя продюсера
Type
"Bug"
Resolution
"Assigned"
Задача 2:
Программист признает, что это баг:
Задача 3:
Resolution
"Fix in Progress"
Задача 4:
Resolution
"Fixed"
Version Fixed
Номер версии
Build Fixed
Номер билда
Assigned to
Имя релиз-инженера
Задача 5:
Resolution
"Build in Progress"
Жизнь замечательных багов
249
и после того, как новый билд появился на тест-машине:
Resolution
"Verify"
Assigned to
Имя лица из Verifier
Задача 6:
Баг НЕ починен:
Задача 7:
Resolution
"Verification Failed"
Assigned to
Имя программиста
Баг починен:
Задача 8:
Resolution
"Fix is Verified"
Status
"Closed"
Обратно к задаче 2:
Программист НЕ признает, что это баг:
Задача 9: