Проверка того, что ремонт бага не наплодил других багов.



Код — это тонкая материя, состоящая из множества взаимо­зависимых компонентов, и чем сложнее ПО, тем труднее пред­угадать, как изменение кода в одном месте отразится на рабо­те всех закоулков системы. Если программист не указывает в комментариях, какая часть ПО может быть попутно затронута ремонтом, я в зависимости от ситуации

• прохожу по приоритетному флоу функциональности, код которой был отремонтирован, и/или

• делаю энд-ту-энд-тест.

Пример с энд-ту-энд-тестом

в функциональности корзины была проблема с тем, что пользователь не мог изменить количество книг. Энд-ту-энд-тест, который бы я сделал:

а) добавить в корзину книгу,

б) изменить количество книг и

в) произвести оплату.


238


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


Таким тестом мы проверяем, что флоу, в которое включен отремонти­рованный компонент, все еще работает.

Изменить резолюцию на Fix is Verified можно непосредственно после успешного завершения части 1.

При значении Fix is Verified можно закрыть баг. После закрытия бага у него нет держателя, так как его некуда больше передавать.

После того как резолюция стала Fix is Verified и до закрытия бага держателем бага является товарищ, который выбрал эту резолюцию.

Verification Failed (ремонт был неуспешен)

Если первая часть регрессивного тестирования показала неус­пешность ремонта, т.е. баг все еще существует в коде, то мы не делаем второй части, а просто выбираем это значение резолюции, после чего держателем бага становится программист, который починил код.

Can Ч Reproduce (не могу воспроизвести)

Эта неприятная для тестировщика резолюция выбирается про­граммистом после того, как перед починкой кода он пытается воспроизвести проблему и не может сделать этого. Как правило, Can 7 Reproduce имеет место в следующих случаях:

• "Описание и шаги..." содержат неполную, неверную или нечеткую информацию о том, как воспроизвести баг, и/или

• бага нет, т.е. тестировщик принял за баг правильно рабо­тающий код.

Одной из основных вещей в отношении багов в ПО является идея об их воспроизводимости, т.е. если баг существует, его можно воспроизвести.Бывает так, что тестировщик, найдя баг в ПО, сразу же открывает СТБ, заносит новый баг и, довольный собой, продолжает работу. Программист же соответственно бросает ра­боту, начинает воспроизводить этот баг и после нескольких не­удачных попыток посылает его обратно тестировщику с резолю­цией Can't Reproduce. Особенно неприятна ситуация, когда опи­сание бага содержит сложную и долгую процедуру, необходимую для воспроизведения.

Лучшим средством превентирования подобных вещей является правило: "Перед тем как занести новый баг, воспроизведи его еще раз",т.е., после того как найден баг, необходимо воспроиз-


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


239


вести его повторно. Это, казалось бы, простое правило поможет и тестировщику, и программисту быть немного счастливее, а наше счастье — это счастье пользователей.

Бывают такие случаи, когда очень сложно выявить условия,ко­торые привели к появлению бага.

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

Условие появления бага — это непосредственная ситуация, воспроиз­ведя которую мы воспроизводим баг. Например, пользователь может добавить кредитную карту с датой истечения действия в прошлом.

Причина появления бага — это конкретная ошибка программиста или продюсера, результатом которой является баг (например, сделана ошибка в логике кода).

Идем дальше.

Например, мы увидели баг и не можем воспроизвести его, совер­шая, казалось бы, те же самые действия, которые привели нас к багу в самом начале. После того как баг не был воспроизведен, мы оставляем наши попытки, так как, если баг существует, его можно воспроизвести,продолжаем работу, а затем снова видим тот же баг и снова не можем его воспроизвести.

Что я могу сказать? Именно такие ситуации бросают вызов на­шему профессионализму. Если баг появился один раз и мы никак не смогли воспроизвести его, то после его второго появления мы ОБЯЗАНЫ найти условия, в результате которых он появляется. Такие условия есть всегда, как порой ни сложно найти их.

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

В одной фармацевтической лаборатории работали четыре сотрудника. Один из них, сотрудник N., изобрел уникальное вещество, которое должно было послужить основой нового лекарства. N. составил под­робный рецепт, но никто из его коллег не смог изготовить то же веще­ство, хотя они в точности выполняли все шаги. Дошло даже до того, что троица, стоя по бокам от Л/., повторяла все его действия, и все-таки вещество получалось только у него одного. В итоге четыре человека с университетским образованием собрались на совещание и решили, что они поверят в мистическое происхождение вещества, но после од­ного последнего теста: АБСОЛЮТНО все действия N. в процессе изго­товления вещества должны были быть засняты на видеокамеру и тща­тельно проанализированы.

После съемки, тщательного анализа и последующих тестов разгадка была найдена: в процессе изготовления вещества сотрудник N. пере­ходил из одной лаборатории в другую по морозной улице.


240


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


Так как он был заядлым курильщиком, то перед выходом на улицу, что­бы освободить руки для зажигалки и сигареты, он клал пробирку с веществом "ближе к сердцу" во внутренний карман пиджака,

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

Мораль сей истории такова: порой мельчайший нюанс может иметь радикальное влияние на конечный результат.

Кстати,

условием (а вернее, одним из необходимых условий) для воспроизве­дения вещества было недопущение охлаждения жидкости в пробирке.

Причиной же появления того или иного итогового вещества были хи­мические процессы.

Итак, стремитесь к тому, чтобы программисты никогда не воз­вращали вам баги с резолюцией Can't reproduce.

Держатель — тот, кто занес баг в СТБ.

Duplicate (дубликат)

Эта резолюция выбирается после того, как повторный баг был занесен СТБ для той же проблемы.

Даже в стартапах в СТБ заносятся сотни и тысячи новых багов, и порой физически нет возможности просмотреть каждый из них, так чтобы постоянно быть в курсе дел и не занести баг — дубли­кат уже существующего. На помощь может прийти модификация ваших персональных настроек СТБ, где можно предусмотреть, что вы будете извещаться е-мейлом о всех багах, имеющих опре­деленные значения определенных атрибутов (например, слово "корзина" в кратком описании).

Такая резолюция позволяет закрыть баг.

Держатель — тот, кто занес баг в СТБ.

Not a bug(не баг)

Это значение резолюции присваивается, как правило, программи­стом, когда возникает ситуация "it's not a bug, it's a feature " ("это не баг, а фича"), т.е. тестировщик принял за баг то, что, по мне­нию программиста, работает правильно.

Когда возникают подобные ситуации? Например, когда тести­ровщик создал тест-кейсы, руководствуясь спеком, а програм­мист создал код, руководствуясь чем-то иным.


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


241


Почему возникает "руководствуясь чем-то иным"? Из-за плохих спеков, когда программист фактически делает работу продюсера, придумывая то, как должны работать функциональности, либо же из-за того, что программист решает просто "забить", скажем, на часть спека и сделать по-своему.

Бывает также, что либо тестировщик, либо программист, либо оба из них неправильно поняли спек.

Бывает также, что программист просто "пропустил" часть спека и не написал для этой части код.

Причин множество.

Как правило, после того как программист возвращает мне баг с Not a bug, я читаю его комментарии и принимаю решение о за­крытии бага или возврате его программисту (меняю резолюцию на Assigned и меняю мое имя в Assigned to на имя программиста) с моими комментариями.

Кстати, в зависимости от СТБ и ее настроек значения атрибутов могут быть

а) взаимозависимыми или

б) нет.

Примеры

а) значение атрибута 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


Основа его работы — координациямежду такими частями про­екта, как идея, дизайн, кодирование и тестирование, и всеми связан­ными с ними нюансами типа сроков, людей и прочих ресурсов.

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

Менеджер проекта — это первый и главный контакт, кото­рый должен быть в курсе событий, знать состояние дел и знать, кто за что отвечает, чтобы быстро и точно переадресо­вать проблему тому, кто ее может решить.

Кстати, термин "проект" употребляется здесь (в разговоре о менед­жерах проекта) в двух значениях:

некая часть ПО, например, "Оплата". У Оплаты может быть свой менеджер проекта, который на постоянной основе ведает всеми делами, связанными с ней;

новая инициатива, например, под названием "Обновление архи­тектуры базы данных".

Хороший менеджер проекта — это благословение проекта, пло­хой — его проклятие. Любимое развлечение плохих менеджеров проекта — организация бесконечного числа бесконечных сове­щаний с переливанием из пустого в порожнее.

Кстати, я однажды подсчитал, сколько денег компания тратила на ка­ждое из совещаний по одному из проектов, — цифра была более чем внушительная. Вот формула для консервативного подсчета стоимости одного совещания, может быть, пригодится как-нибудь:

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, как пра­вило, возникают из-за отсутствия информации.

В моей практике, если фактический результат после исполнения тест-кейса расходится с ожидаемым результатом по этому тест-кей­су, я пытаюсь воспроизвести баг заново, и если он воспроизводится, то я сразу же заношу его в СТБ. Если же я вижу проблему, которая не связана с моим ожидаемым результатом и/или функциональ­ностью, о которой я имею полную информацию, то обычно контак­тирую с коллегами-тестировщиками, которые владеют вопросом о функциональности, в которой, как мне кажется,есть баг.

Резолюция No longer applicable позволяет закрыть баг, если он на самом деле больше не баг.

Процесс трэкинга багов

Теперь, после того как мы поговорили об атрибутах СТБ, посмот­рим на блок-схему. На ней мы воочию видим основу процесса трэкинга багов. Эта основа сама по себе является стандартной версией процесса, и интернет-компании используют ее в таком либо измененном виде.


246


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


Процесс трэкинга багов


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


247


Кстати, для упрощения допустим, что баг заносится тестиров-щиком (хотя мы знаем, что баг может заноситься кем угодно) и против кода программиста (хотя мы знаем, что существуют и баги спека, которые заносятся против продюсера).

Давайте сделаем так:

• сначала рассмотрим процесс концептуально, затем

• привяжем к каждой его стадии наши атрибуты (детальное рассмотрение процесса), затем

• приведем конкретный пример.


Дата добавления: 2018-05-02; просмотров: 677; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!