tестирование dot com
Шрифт:
Это ниспадающее меню с тем же списком имен сотрудников, что
и в Assigned to.
Как мы помним, баг может быть занесен в СТБ любым сотрудни-
ком интернет-компании, который имеет счет в СТБ и соответст-
вующую привилегию.
При занесении бага значение Verifier автоматически становится
равным имени автора бага. После того как баг был зафиксирован
224
Тестирование Дот Ком. Часть 3
и отремонтированный код был доставлен
телем бага должно стать лицо, указанное в Verifier.
Как правило, если баг заносится не тестировщиком, то "нетести-
ровщик" сразу (при занесении) выбирает значение Verifier, чтобы
умыть руки и позабыть об этом баге навсегда.
Кстати, каждый эккаунт в СТБ принадлежит к определенной группе.
Как минимум таких групп 3:
• "Тестировщики" — сотрудники департамента качества;
• "Программисты" — сотрудники департамента программирования;
• "Прочие" — все остальные.
В зависимости от принадлежности эккаунта к определенной группе
определяются его привилегии. Например, закрыть баг может только
тот, кто принадлежит к группе "Тестировщики".
Кстати, можно настроить СТБ так, чтобы, когда "Прочие" заносят баг,
значение Verifier не становилось автоматически равным Submitted By, a
было пустым и "Прочие" обязаны (под страхом незанесения бага) вы-
брать значение Verifier.
Не будем больше о привилегиях, это отдельная песня, зависящая
от компании и возможностей СТБ.
COMPONENT (КОМПОНЕНТ)
Это ниспадающее меню со списком, как правило, функциональ-
ных частей веб-сайта. Например, этот список вполне может быть
таким вот коротким и скромным:
"Регистрация
Поиск
Корзина
Оплата
Другое"
При занесении бага в СТБ автор бага должен выбрать компонент,
тестируя который он нашел заносимый баг. Что я могу еще сказать?..
FOUND ON (ГДЕ БЫЛ НАЙДЕН БАГ)
Это ниспадающее меню, которое включает
• имена тест-сайтов, обитающих на нашей тест-машине;
• скромное слово "ZJFЈ"' (машина для пользователей);
• Spec ("Спек");
• Other ("Другое").
Жизнь замечательных багов
225
Например, в нашем любезном сердцу проекте (www.testshop.rs)
список Found on состоит
из следующих друзей:"www.old.testshop.rs,
www.main.testshop.rs,
LIVE,
Spec,
Other".
Понятно, что если значение Found on равно "LIVE", то это означа-
ет, что был пропущен баг, который через релиз добрался до ма-
шины для пользователей или, как говорят некоторые любители
повыпендриваться, "Баг вышел на продакшн". Found on является
обязательным для заполнения.
Немедленная польза от использования атрибута Found on заклю-
чается в том, что каждый, кто хочет воспроизвести занесенный
баг, знает, где конкретно это можно сделать.
VERSION FOUND
(ВЕРСИЯ, В КОТОРОЙ БЫЛ НАЙДЕН БАГ)
Это ниспадающее меню с версиями веб-сайта, автор бага обязан
выбрать значение, соответствующее номеру версии продукта, в
которой был найден баг.
BUILD FOUND (БИЛД, В КОТОРОМ БЫЛ НАЙДЕН БАГ)
Это небольшое (примерно 10 символов) текстовое поле, куда ав-
тор бага обязан вбить номер билда, в котором был найден баг.
VERSION FIXED (ВЕРСИЯ С ПОЧИНЕННЫМ КОДОМ)
Это ниспадающее меню с версиями веб-сайта. После того как
программист починил баг, он должен передать этот баг далее (ре-
лиз-инженеру), для того чтобы в итоге Verifier произвел регрес-
сивное тестирование (у нас будет подробное объяснения процес-
са через 5 минут). Программист обязан выбрать номер версии,
соответствующий бранчу в CVS, куда он направил отремонтиро-
ванный код.
Version Fixed может иметь, как одно из значений, "N/A " (Not ap-
plicable — "к данной ситуации неприменимо"), которое продюсер
обязан выбрать, зафиксировав баг, найденный в спеке.
226
Тестирование Дот Ком. Часть 3
BUILD FIXED
(БИДД С ПОЧИНЕННЫМ КОДОМ)
Это небольшое (например, 10 символов) текстовое поле, которое
заполняется в то же время, что и Version Fixed, т.е. после починки
бага и помещения починенного кода в CVS. В Build Fixed про-
граммист обязан указать номер следующего билда, который под-