сти менеджера проекта исполняют продюсеры.

244

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

Итак, обратно к "не нашему" ПО.

Во многих случаях наш веб-сайт так или иначе связан с ПО, ко-

торое принадлежит нашим бизнес-партнерам и ими же поддер-

живается в рабочем состоянии, например это ПО для процессинга

кредитных карт.

Так вот если найденный баг является багом в таком ПО, то тот,

кто исполняет обязанности менеджера проекта, набирает номер

ответственного лица на стороне наших бизнес-партнеров и коор-

динирует действия между нашей и не нашей стороной (например,

нашим и не нашим программистами) по разрешению проблемы.

Может, это и не баг вовсе, а недопонимание нами, как работает

не наше ПО.

Если же это баг, то наш партнер заносит запись о нем в собствен-

ную СТБ.

Далее.

Если это баг, то могут быть следующие варианты:

• баг имеет место быть на не нашей тест-машине, т.е. наша

тест-машина "разговаривает" с их тест-машиной и/или

• баг имеет место быть на не нашей машине для пользовате-

лей (мы выступаем в роли пользователей), т.е. наша машина

для пользователей "разговаривает" с их машиной для поль-

зователей.

В зависимости от того, где был найден баг в не нашем ПО и от

его важности для нас, а соответственно для нашего контрагента,

назначается приоритет, от которого зависит и скорость починки.

Всю координацию от "А" до "Я" с нашей стороны осуществляет

тот, кто исполняет обязанности менеджера проекта.

Итак, если мы можем повлиять на производителей не нашего ПО

и программист вернул вам баг с резолюцией 3rd party bug, вы в

Assigned to выбираете имя того, кто исполняет обязанности ме-

неджера проекта, и, сопровождая баг своими комментариями,

делаете его держателем бага. Он со своей стороны после выясне-

ния: "Кто виноват? Что делать? и Едят ли курицу руками?" —

может вернуть вам баг с резолюцией Not a Bug (если это был не

баг, а недопонимание того, как работает не наше ПО) либо же

вернуть вам баг (путем Assigned to) с той же резолюцией — 3rd

party bug, и вы в обоих случаях спокойно его закроете.

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

245

Важно: в обоих случаях (когда мы не можем/можем повлиять на

производителя не нашего ПО) наш программист может ошибочно

допустить, что проблема в не нашем ПО, хотя на самом деле это

наш баг. В этом случае тестировщик делает:

Resolution — Assigned

Assigned to — имя программиста.

No longer applicable (поезд ушел)

Такое значение резолюции присваивается багу, который раньше

действительно был багом, но теперь по какой-то причине тако-

вым не является.

Например

мы исполняем тест-кейс по проверке одного из флоу функционально-

сти "Оплата" и видим, что отсутствует поле для ввода номера CW2. Мы

заносим баг и получаем его обратно с резолюцией No Longer Applicable

и комментарием программиста, что согласно багу #7723 с типом "Fea-

ture Request" мы больше не должны спрашивать CW2 у пользователя.

Таким образом, до занесения продюсером бага #7723 ситуация с от-

сутствующим CW2 была бы багом, а теперь это не баг.

Баги, возвращенные с резолюцией No longer applicable, как пра-

вило, возникают из-за отсутствия информации.

В моей практике, если фактический результат после исполнения

тест-кейса расходится с ожидаемым результатом по этому тест-кей-

су, я пытаюсь воспроизвести баг заново, и если он воспроизводится,