tестирование dot com
Шрифт:
принял решение, что с этим багом делать.
Важный момент: если проблема была в спеке, то продюсер ста-
новится держателем бага (после того как я изменю Not a bug на
Assigned и выберу имя продюсера в Assigned to), и он должен из-
менить резолюцию на Verify после того, как спек будет изменен.
Я поменяю
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
Основа его работы — координация между такими частями про-
екта, как идея, дизайн, кодирование и тестирование, и всеми связан-
ными с ними нюансами типа сроков, людей и прочих ресурсов.
Можно также провести аналогию с должностью директора кар-
тины в советском кинематографе, который мог ничего не пони-
мать в работе оператора, но который знач все ходы и выходы,
чтобы достать и пленку, и аппаратуру, и самого оператора.
Менеджер проекта — это первый и главный контакт, кото-
рый должен быть в курсе событий, знать состояние дел и
знать, кто за что отвечает, чтобы быстро и точно переадресо-
вать проблему тому, кто ее может решить.
Кстати, термин "проект" употребляется здесь (в разговоре о менед-
жерах проекта) в двух значениях:
• некая часть ПО, например, "Оплата". У Оплаты может быть свой
менеджер проекта, который на постоянной основе ведает всеми
делами, связанными с ней;
• новая инициатива, например, под названием "Обновление архи-
тектуры базы данных".
Хороший менеджер проекта — это благословение проекта, пло-
хой — его проклятие. Любимое развлечение плохих менеджеров
проекта — организация бесконечного числа бесконечных сове-
щаний с переливанием из пустого в порожнее.
Кстати, я однажды подсчитал, сколько денег компания тратила на ка-
ждое из совещаний по одному из проектов, — цифра была более чем
внушительная. Вот формула для консервативного подсчета стоимости
одного совещания, может быть, пригодится как-нибудь: