tестирование dot com
Шрифт:
total cost of meeting =
= number of participants x median hourly rate x number of hours,
где total cost of meeting — сколько стоит компании одно совещание;
number of participants — число присутствующих на совещании; median
hourly rate — средняя заработная плата в час. Заработная плата каждого
—
величине, исходя хотя бы из вашей собственной заработной платы; number of
hours — количество часов, которое длится совещание.
Я встречал PJ'MOB очень разных квалификаций и навыков в обще-
нии. Бывали даже случаи, когда я шел к своему менеджеру и про-
сил его дать мне другой проект, так как не хотел работать с неким
конкретным менеджером проекта.
В подавляющем большинстве случаев в стартапах обязанно-
сти менеджера проекта исполняют продюсеры.
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, как пра-
вило, возникают из-за отсутствия информации.
В моей практике, если фактический результат после исполнения
тест-кейса расходится с ожидаемым результатом по этому тест-кей-
су, я пытаюсь воспроизвести баг заново, и если он воспроизводится,