Проверка того, что ремонт бага не наплодил других багов.
Код — это тонкая материя, состоящая из множества взаимозависимых компонентов, и чем сложнее ПО, тем труднее предугадать, как изменение кода в одном месте отразится на работе всех закоулков системы. Если программист не указывает в комментариях, какая часть ПО может быть попутно затронута ремонтом, я в зависимости от ситуации
• прохожу по приоритетному флоу функциональности, код которой был отремонтирован, и/или
• делаю энд-ту-энд-тест.
Пример с энд-ту-энд-тестом
в функциональности корзины была проблема с тем, что пользователь не мог изменить количество книг. Энд-ту-энд-тест, который бы я сделал:
а) добавить в корзину книгу,
б) изменить количество книг и
в) произвести оплату.
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 с типом "Feature Request" мы больше не должны спрашивать CW2 у пользователя. Таким образом, до занесения продюсером бага #7723 ситуация с отсутствующим CW2 была бы багом, а теперь это не баг.
Баги, возвращенные с резолюцией No longer applicable, как правило, возникают из-за отсутствия информации.
В моей практике, если фактический результат после исполнения тест-кейса расходится с ожидаемым результатом по этому тест-кейсу, я пытаюсь воспроизвести баг заново, и если он воспроизводится, то я сразу же заношу его в СТБ. Если же я вижу проблему, которая не связана с моим ожидаемым результатом и/или функциональностью, о которой я имею полную информацию, то обычно контактирую с коллегами-тестировщиками, которые владеют вопросом о функциональности, в которой, как мне кажется,есть баг.
Резолюция No longer applicable позволяет закрыть баг, если он на самом деле больше не баг.
Процесс трэкинга багов
Теперь, после того как мы поговорили об атрибутах СТБ, посмотрим на блок-схему. На ней мы воочию видим основу процесса трэкинга багов. Эта основа сама по себе является стандартной версией процесса, и интернет-компании используют ее в таком либо измененном виде.
246
Тестирование Дот Ком. Часть 3
Процесс трэкинга багов
Жизнь замечательных багов
247
Кстати, для упрощения допустим, что баг заносится тестиров-щиком (хотя мы знаем, что баг может заноситься кем угодно) и против кода программиста (хотя мы знаем, что существуют и баги спека, которые заносятся против продюсера).
Давайте сделаем так:
• сначала рассмотрим процесс концептуально, затем
• привяжем к каждой его стадии наши атрибуты (детальное рассмотрение процесса), затем
• приведем конкретный пример.
Дата добавления: 2018-05-02; просмотров: 677; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!