tестирование dot com
Шрифт:
из-за того, что программист решает просто "забить", скажем, на
часть спека и сделать по-своему.
Бывает также, что либо тестировщик, либо программист, либо оба
из них неправильно поняли спек.
Бывает также, что программист просто "пропустил" часть спека
и не написал для этой части код.
Причин множество.
Как правило, после того как программист возвращает мне баг с
Not a bug, я читаю его комментарии и принимаю решение о за-
крытии бага или возврате его программисту (меняю резолюцию
на Assigned и
с моими комментариями.
Кстати, в зависимости от СТБ и ее настроек значения атрибутов могут быть
а) взаимозависимыми или
б) нет.
Примеры
а) значение атрибута Assigned to меняется автоматически в зависи
мости от резолюции:
если программист выбрал Not a bug, значение Assigned to само ме-
няется на имя лица, занесшего баг в СТБ;
б) значение атрибута Assigned to статично:
после того как программист выбрал резолюцию Not a Bug, он дол-
жен самостоятельно изменить значение Assigned to на имя лица,
занесшего баг в СТБ.
Обратно к Not a bug.
Если нужно, я уточняю у самого программиста дополнительные
детали, и если мы не приходим к консенсусу о том, закрывать баг
либо начать ремонт, то я меняю Not a bug на Assigned, выбираю в
Assigned to имя продюсера и пишу в комментариях, чтобы тот
принял решение, что с этим багом делать.
Важный момент: если проблема была в спеке, то продюсер ста-
новится держателем бага (после того как я изменю Not a bug на
Assigned и выберу имя продюсера в Assigned to), и он должен из-
менить резолюцию на Verify после того, как спек будет изменен.
Я поменяю резолюцию на Fix is Verified, если своими глазами
242
Тестирование Дот Ком. Часть 3
увижу, что спек на самом деле был изменен, изменение было
правильным и спек находится в том месте интранета компании,
где он должен находиться.
Кстати, в некоторых компаниях качество работы тестировщика оцени-
вается (конечно, наряду с прочими факторами) по тому, сколько багов
было закрыто с резолюцией Not a bug от общего количества найден-
ных им багов в том смысле, что, чем больше нот-э-багов, тем хуже по-
работал тестировщик.
В случае если баг, возвращенный с Not a bug, на самом деле не баг,
то держателем становится автор бага и баг может быть закрыт.
3rd party bug (не наш баг)
Во всех интернет-компаниях уже используют ПО, написанное дру-
гими софтверным компаниями, например интерпретатор для лю-
бимого мною языка Python. Допустим, что я нахожу баг и заношу
его в СТБ. Программист начинает поиск причины бага и видит,
что его код работает чики-пики и корень зла находится в "не на-
шем" ПО, которое каким-либо образом связано с нашим кодом.
Что делает программист? Правильно — возвращает мне баг с ре-
золюцией 3rd party bug.
Что может быть дальше?
Вариант 1: мы не можем повлиять на производителей "не нашего'"
ПО так, чтобы они зафиксировали свою проблему (которая стала
нашим багом).
Например, если проблема была в интерпретаторе Python, то един-
ственное, что мы можем сделать, — это найти обходной путь
(workaround). Для того чтобы программист начал искать такой
путь, мы должны оправдать его усилия тем, что закроем баг с ре-
золюцией 3rd party bug и занесем новый баг, над которым он и
станет работать.
Важный момент: этот новый баг будет с типом "Feature Request".
Вариант 2: мы можем повлиять на производителей "не нашего'"
ПО так, чтобы они зафиксировали свою проблему (которая стала
нашим багом).
Одним из видов особей, обитающих в софтверных компаниях,
являются менеджеры проекта (Project Manager or PjM). Менед-
жер проекта — это администратор, который отвечает за проект.
Жизнь замечательных багов
243
Основа его работы — координация между такими частями про-
екта, как идея, дизайн, кодирование и тестирование, и всеми связан-
ными с ними нюансами типа сроков, людей и прочих ресурсов.
Можно также провести аналогию с должностью директора кар-
тины в советском кинематографе, который мог ничего не пони-
мать в работе оператора, но который знач все ходы и выходы,