tестирование dot com

Савин Роман

• продюсеры, которые отвечают за эти компоненты.

Пример

Компонент

Программист

Продюсер

Регистрация

Н. Гусев

С. Попов

Поиск

Р. Буйнов

А. Ключникофф, А. Зубков

Корзина

Ю. Тимофеев, И. Николаев В. Жабров

Оплата

О. Столяров

В. Новоселов

Нужно, чтобы эта страничка постоянно поддерживалась,

напри-

мер, менеджерами программистов и продюсеров, чтобы отражать

текущее состояние компонентов и ответственных лиц:

если в компании 3 человека, сидящие в одном закутке 4x3 метра,

то каждый примерно знает, что делают двое других. Если же

компания растет и развивается, работники приходят, перево-

дятся с участка на участок, уходят, функциональности появля-

ются, модифицируются, исчезают... в общем перемены бьют

ключом, то наличие централизованного источника информации

о программистах и продюсерах — собственниках функцио-

нальностей является наиудобнейшей и наиполезнейшей вещью

(хотя бы для того, чтобы быстро и правильно выбрать имя из

"Assigned to ").

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

223

Кстати, автором бага может быть не только тестировщик. Любой поль-

зователь СТБ, имеющий право (privilege) на занесение багов в СТБ,

может быть автором бага. Технически права даруются (как, впрочем,

и отнимаются) администратором СТБ.

Кстати, выражение "занести баг" по-аглицки звучит как "file a bug" или

"reporta bug".

Кстати, программисты часто заносят баги против своего же кода. Это

не мазохизм, а холодный расчет, так как

• с одной стороны, сохранять баги в СТБ просто удобно, а

• с другой — программист должен тратить время на ремонт бага, и

баг, занесенный в СТБ, оправдывает такую трату в глазах началь-

ства,

коллег и семьи.

Кстати, программисты любят играть багом в пинг-понг, меняя значе-

ние Assigned to на имена друг друга, говоря таким образом: "Это, доро-

гой, не мой, а твой баг", "Нет, я думаю, что это как раз твой баг", "Я не

уверен, что ты прав. Этот баг все-таки твой" и т.д. Результатом таких

игр является задержка в фиксировании бага.

Небольшой нюанс. Люди приходят в интернет-компанию и уходят

из нее. Когда они приходят, администратор СТБ создает им счета,

а когда они уходят, то эти счета НИКОГДА не удаляются: админист-

ратор СТБ просто маркирует счет бывшего коллеги как недействи-

тельный, т.е. им нельзя больше пользоваться. При этом имя пользо-

вателя СТБ в списке пользователей СТБ остается. Принцип неудале-

ния нужен для сохранения данных, связанных с занесенными багами.

ASSIGNED BY (ИМЯ ПЕРЕДАВШЕГО БАГ)

Значение этого атрибута (как и Submitted by) является нередактируе-

мым текстом. СТБ автоматически присваивает атрибуту Assigned by

имя пользователя СТБ, который выбрал значение Assigned to. Таким

образом, счастливчик, который стал Assigned to, всегда знает, кто

был тем доброжелателем, который сделал его держателем бага.

VERIFIER (ИМЯ ТОГО, КТО ДОЛЖЕН ПРОВЕРИТЬ РЕМОНТ)

Это ниспадающее меню с тем же списком имен сотрудников, что

и в Assigned to.

Как мы помним, баг может быть занесен в СТБ любым сотрудни-

ком интернет-компании, который имеет счет в СТБ и соответст-

вующую привилегию.

При занесении бага значение Verifier автоматически становится

равным имени автора бага. После того как баг был зафиксирован

224

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

и отремонтированный код был доставлен на тест-машину, держа-

телем бага должно стать лицо, указанное в Verifier.

Как правило, если баг заносится не тестировщиком, то "нетести-

ровщик" сразу (при занесении) выбирает значение Verifier, чтобы

умыть руки и позабыть об этом баге навсегда.

Кстати, каждый эккаунт в СТБ принадлежит к определенной группе.

Как минимум таких групп 3: