Роман Савин - тест dot com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
 Скачать 5.26 Mb.
|
|
SEVERITY (СЕРЬЕЗНОСТЬ БАГА) Форма: ниспадающее меню со значениями от О до С4 (51—4) включительно. Содержание: серьезность бага — это степень воздействия бага (magnitude of impact) на ПО, исходя из принадлежности бага к определенной технической категории. Жизнь замечательных багов 227 Вот пример категоризации: Серьезность бага Определение С1 — Критический (Critical) • критический системный сбой (crash); • потеря данных (data loss); • проблема с безопасностью (security issue) С2 — Значительный (Major) • сайт "зависает" (site hangs); • баг блокирует кодирование, тестирование или использование веб-сайта (blocker) СЗ — Умеренный (Minor) • функциональные проблемы (functional bugs) С 4 — Косметический (Cosmetic) • косметическая проблема (cosmetic problem) Примеры С1— КРИТИЧЕСКИЙ Критический системный сбой — ситуация, когда какая-то часть ПО на машине для пользователей "рушится" — например, нажимаете на кнопку "Поиск" и получаете ошибку "HTTP Error 500 Internal server error". Потеря данных (data loss) — чаще всего это происходит, когда данные: а) не достигают базы данных либо б) незапланированно удаляются из нее. Например: а) при регистрации е-мейл пользователя не вставляется в опреде ленную колонку определенной таблицы базы данных; б) при обновлении пользователем адреса на фронтенде старый адрес удаляется из базы данных. Проблема с безопасностью — например, когда после логина пароль виден как часть URL, так что кто-то может подсмотреть пароль и ис- пользовать его в своих корыстных целях. При современном состоянии дел в Интернете, когда 4% монетарных транзакций осуществляется мошенниками, безопасность — вещь первостепенная. С2 — ЗНАЧИТЕЛЬНЫЙ Веб-сайт "зависает" — одна из основных бед интернет-проектов, на- пример, нажимаешь на кнопку "Купить", и следующая страница грузится, и грузится, и грузится... Как правило, после таких "загрузов" очень хочется попробовать веб-сайт конкурента. Баг блокирует кодирование, тестирование или использование вебсайта — ситуация, когда работа тестировщика (и/или программиста) и/или использование веб-сайта не могут быть продолжены, так как на одном из этапов появляется про- блема, превентирующая дальнейшее продвижение. 228 Тестирование Дот Ком. Часть 3 Например, пользователь не может добавить кредитную карту к своему эккаунтуи, следовательно, не может ничего купить на нашем веб-сайте. Термин "блокирование" также связан с понятием "обходной путь" (work- around), а вернее, с отсутствием этого пути. Например, согласно тест- кейсу нужно создать эккаунт путем использования тест-тула, но тест-тул не работает (баг в тест-туле является абсолютно легитимным багом!). Если есть возможность найти обходной путь, который разблокировал бы в данной ситуации тестирование, то баг не является блокирующим и не подходит под С2. Примером обходного пути в данном случае является создание эккаунта вручную. СЗ — УМЕРЕННЫЙ Функциональные проблемы (functional bugs) — под эту категорию подходят все функциональные баги, не подходящие под С1 и С2. Как правило, это простое расхождение между фактическим и ожидаемым результатами, когда все шаги тест-кейса (все этапы флоу) исполнены. СА — КОСМЕТИЧЕСКИЙ Косметическая проблема — баги, связанные с содержанием вебсайта (content), правописанием (spelling) и интерфейсом пользователя (User Interface). Значение серьезности бага обязательно должно быть выбрано из списка, иначе баг нельзя занести в СТБ. PRIORITY (ПРИОРИТЕТ БАГА) Форма: ниспадающее меню со значениями от Ш до П4 (Ш—4) включительно. Содержание: приоритет бага — это показатель важности бага для бизнеса компании. Кстати, многие товарищи путают приоритет и серьезность. Ко- ренное различие между ними кроется в том, что серьезность отражает технический аспект бага, а приоритет — коммер- ческий. Серьезность — это категория абсолютная. Приоритет — это категория относительная. Так, если сайт рушится (crash), то это С1, и мы не можем, на- пример, по политическим соображениям изменить серьезность такого бага, например, на С2, так как ситуация (с системным сбоем) четко соответствует дефиниции С1. Если же тести- ровщик назначил приоритет как П1, то программист вполне Жизнь замечательных багов 229 может оспорить такое решение и в итоге приоритет будет П2. Таким образом, назначение серьезности — это механическое дей- ствие, а приоритета — творческое, связанное с оценкой угрозы бага для бизнеса компании. Часто в документации процесса и настройках СТБ определена четкая связь между верхними значениями серьезности и приори- тета. Например, если установлено, что "при серьезности С1 значение при- оритета должно быть П1", и тестировшик выбирает С1 и П2, то СТБ не позволит занести баг и выдаст ошибку. В большинстве же случаев, т.е. при СЗ (функциональных) багах, нет четкой зависимости между серьезностью и приоритетом, и в "Описании и шагах..." иногда стоит объяснить, почему вы выбрали именно этот приоритет, а не более высокий или более низкий. Кстати, П1 — баг, из-за которого может сорваться запланированный релиз, называется showstopper ("пробка"). Примером такого бага мо- жет служить ситуация, когда тестирование функциональности "Оплата" полностью заблокировано из-за бага во вспомогательном ПО, симули- рующем платежную систему. Еще пара слов о связи серьезности и приоритета бага: например, мы имеем дело с судопроизводством, а не интернет-проектом. Фраза "казнить нельзя помиловать" содержит баг, так как от- сутствует запятая. Отсутствие запятой — это С4, но ситуация, когда может быть наказан невиновный или оправдан преступник, — это П1. Ну, например, из-за величины негативных последствий для имиджа правосудия (шутка). Кроме привязки к серьезности бага на приоритет могут воздейст- вовать следующие потенциальные либо реальные вещи: • процент затронутых пользователей, • денежные потери для компании, • негативные юридические последствия для компании, • негативные последствия для имиджа компании. В каждой компании должны быть дефиниции приоритета багов (bug priority definitions), в которых обязательным элементом яв- ляется указание сроков для починки багов (дополнительным эле- ментом могут быть факторы, указанные выше, например процент затронутых пользователей). 230 Тестирование Дот Ком. Часть 3 Вот простейший пример дефиниций. Приоритет бага Дефиниция П1 Брось все дела и зафиксируй баг П2 Зафиксируй баг в течение 72 часов ПЗ Зафиксируй баг до завершения тестирования данного основного релиза П4 Зафиксируй, если возможно Примеры П1 —П2 — все понятно. ПЗ — каждая стадия цикла разработки ПО имеет свои запланирован- ные временные рамки. Таким образом, если релиз должен состояться 16 марта, то до 16 марта все ПЗ должны быть зафиксированы и закрыты. П4 — такие баги фиксируются, если у программиста есть время. На- пример, в какой-нибудь старой версии браузера интернет/эксплорер (Internet Explorer — IE) не работает какое-нибудь суперзамысловатое флоу, которое вряд ли может прийти кому-либо в голову. У каждой компании есть свои заморочки, но, как правило, все баги П1, П2 и ПЗ должны быть зафиксированы и закрыты до релиза. В случае с ПЗ, если не хватает времени, может приниматься решение о релизе, содержащем баг, с условием, что в течение такого-то периода времени (дни) этот баг будет зафиксирован, протестирован и патч- релиз выпущен на машину для пользователей. Почему принимается такое решение, которое, казалось бы, противо- речит здравому смыслу? Очень просто. Политика, господа: акционеры компании ждут доходов от своих инвестиций, и каждый основной либо дополнительный релиз — это потенциальный катализатор новых прибылей, и такие вещи, как пароч- ка незафиксированных ПЗ, в мире чистогана в расчет не принимаются. Кроме того, менеджменту придется держать ответ перед теми же акцио- нерами, почему релиз не был выпущен вовремя. Иногда опять же по политическим соображениям принимается реше- ние о понижении приоритета бага со всеми вытекающими отсюда по- следствиями, например, когда П2 понижается до ПЗ и этот ПЗ выпус- кается на продакшн. Приоритет обязательно должен быть выбран из списка, иначе баг нельзя занести в СТБ. В случае сомнений в том, какой приоритет поставить, например ПЗ или П2, я обычно иду по пути повышения приоритета, т.е. выбираю П2. Как говорится, не корысти ради, а во благо наших дорогих и любимых пользователей. Жизнь замечательных багов 231 Иногда возникают конфликтные ситуации, когда программист считает, что приоритет завышен, а тестировщик утверждает, что "сам ты такой" и приоритет назначен правильно. В таком случае вы можете попросить своего менеджера принять решение о сни- жении приоритета, если вы считаете, что поставленный вами приоритет верен и не хотите снижать его сами. Помните, что дружба дружбой, а если вы были заблокированы и из-за люб- ви к своему программисту поставили ПЗ вместо Ш, то про- блемы с невыполнением плана будут у вас, а не у него, так как это вы, а не он можете не закончить в срок исполнение тестирования. Приоритет — это мощнейший инструмент, используя который вы влияете на расписание работы программиста, поэтому не зло- употребляйте им (приоритетом) и используйте его мудро. NOTIFY LIST (СПИСОК ДЛЯ ОПОВЕЩЕНИЯ) Это ниспадающее меню со списком алиасов всех пользователей, зарегистрированных в СТБ. Во многих случаях тестировщику не- обходимо, чтобы • о факте занесения бага и • о любом изменении в самой записи о баге знал определенный круг людей. Оповещение происходит с помощью е-мейла, в который вклю- чаются: • номер бага; • статус; • краткое описание; • приоритет; • серьезность бага; • название, старое и новое значение измененного атрибута (например, кто-то занес свое мнение в комментарий); • имя того, кто покусился изменить баг (либо занести новый баг в СТБ). Кстати, каждый пользователь СТБ может отрегулировать настройки оповеще- ния как ему удобно, например, можно сделать так, чтобы е-мейл посы- лался каждый раз, когда заносится баг, упоминающий в кратком опи- сании некий спек, например, за номером 7611. 232 Тестирование Дот Ком. Часть 3 Как правило, по умолчанию • после занесения бага е-мейл посылается автору бага и держателю бага, • а при изменении записи о баге — автору бага, держателю бага и лицу, изменившему баг. Настройками оповещения, общими для всех участников процес- са, ведает, как вы уже догадались, администратор СТБ. Таким образом, атрибут "Список для оповещения" используется автором бага либо другим заинтересованным лицом для того, чтобы е-мейлы посылались тем, кто не является реципиентом по умолчанию. Я всегда включаю в "Список для оповещения" имя продю- сера, чтобы тот знал о состоянии дел, связанных с тестирова- нием его спека. Выбор значений для данного атрибута не является обязательным. CHANGE HISTORY (ИСТОРИЯ ИЗМЕНЕНИЙ) Это наиважнейший, автоматически заполняемый атрибут. Суть его в том, что любое изменение бага отражается в нередактируе- мом многострочном текстовом поле в следующем формате: • дата и время изменения (date and time of change); • имя лица, изменившего баг (who changed); • название измененного атрибута (what was changed); • предыдущее значение атрибута (previous value); • новое значение атрибута (new value). Запомните, что любые действия любого лица, имеющего счет в СТБ, автоматически записываются, запись доступна для всех пользователей СТБ и не подлежит редактированию. Таким обра- зом, можно до секунды увидеть, что конкретно, как конкретно и кем конкретно было изменено. Анонимность, столь любимая по- сетителями интернет-форумов, полностью исключена. Жизнь замечательных багов 233 TYPE (ТИП БАГА) Это ниспадающее меню со значениями: • bug (баг), • feature request (запрос о фича). По умолчанию значение типа бага (типа записи) — это "баг", т.е. расхождение между фактическим и ожидаемым результатом, и 95% багов (записей) в СТБ имеет значение "баг". Компьютерный термин "Feature " не имеет эквивалентного тер- мина в русском языке, и мы можем • либо изобрести новое слово, • либо позаимствовать существующее слово из английского языка и соответственно писать его русскими буквами (что мы и сделаем). Я всегда стараюсь найти подходящий перевод английской тер- минологии, но иногда это просто не удается, и хотя заимство- ванные слова, написанные кириллицей, могут поначачу коробить слух и глаз, это вещь вполне легитимная. Например, книга Васи- лия Аксенова "В поисках грустного бэби" изобилует такими сло- вами, так как многие из них просто невозможно правильно пере- вести (например, "плаза "). Кроме того, есть термины, устояв- шиеся в профессиональной среде (например, наша "фича "). Итак, фича — это в зависимости от контекста • функциональность либо • характеристика (или свойство) компонента кода, интер- фейса, базы данных и пр. Например Значение "функциональность" работает, если мы говорим о кепча. Значение "характеристика" работает, если мы говорим об оптимиза- ции кода с целью улучшения перформанса (скорости работы сайта). Обратно к Feature request. Баг с типом Feature request заносится в СТБ с именем продюсера или программиста в Assigned to, когда у вас родилась идея об улучшении некой существующей фича или о новой фича. Значение типа Feature request также используется в баге, служа- щем основанием для патч-релиза, в случае, когда появилась не- 234 Тестирование Дот Ком. Часть 3 обходимость в срочном изменении кода на машине для пользо- вателей и это изменение не связано с багом (как отклонением фактического от ожидаемого). Логичным будет вопрос: почему мы употребили выражение "срочное изменение"? Вот ответ: если нужна новая функциональность, то продюсер пишет спек, программист его кодирует и т.д. в соответствии с про- цессом разработки ПО. Каждая стадия процесса имеет свои вре- менные рамки, которые привязаны к расписанию релизов (release schedule). А что, если у нас появилась незапланированная потреб- ность в новой фича и ее нужно срочно выпустить? Пример Допустим, мы выпускаем один основной релиз в месяц. Сегодня 10 ноября, и последний основной релиз (7.0) состоялся 31 октября. Если сегодня (Ю ноября) появилась новая идея (например, о добавле- нии кепча на страницу регистрации), то если мы включим ее в наш процесс разработки как любую очередную идею, то наша многостра- дальная кепча появится на машине для пользователей не 1 декабря в релизе 8.0 (так как все спеки релиза 8.0 уже заморожены), а 1 января в релизе 9.0. Таким образом, придется ждать больше полутора меся- цев. Что делать, если у нас нет полутора месяцев, а есть полтора часа ? Нужно занести баг "Feature request" с приоритетом П1. Если же фича может подождать до 8.0, то опять же заносим баг с типом "Feature re- quest", но уже с приоритетом ПЗ. Вот такие дела... STATUS (СТАТУС) Это ниспадающее меню со значениями: • Open (Открыт), • Closed (Закрыт), • Re-Open (Повторно открыт). Значение Open присваивается багу автоматически при занесении бага. Закрыть баг можно только при соответствующей резолюции (об этом через минуту). Значение Re-Open выбирается тестировщиком, когда он возрож- дает к жизни закрытый баг. Почему возникают ситуации, когда баги приходится открывать заново? Жизнь замечательных багов 235 Например • программист сделал изменение в коде и поломал отремонтиро- ванный ранее код, так что проблема появилась заново. В этом слу- чае говорят о том, что баг был reintroduced ("заново внесен на рас- смотрение" — так себе перевод, но ничего лучше я не нашел); • баг был найден на машине для пользователей. Программист сде- лал checkin отремонтированного кода в бранч-версии машины для пользователей и позабыл сделать checkin в ствол. Следовательно, в следующем релизе баг появляется снова. В связи со статусом запомним две вещи: • ВСЕ найденные баги должны заноситься в СТБ. Исклю- чений быть не может. Ваша работа как тестировщика — искать баги. Единственный и неповторимый результат вашей работы — баг, занесенный в СТБ. Умные программисты ни- когда на вас не обидятся, так как качество их работы измеря- ется не количеством багов, ими допущенных, а скоростью, с которой они эти баги чинят (почти по Глебу Жеглову); • занесенные в СТБ баги НИКОГДА не удаляются из СТБ. Чтобы ни случилось, пока живет компания, ее СТБ вклю- чает ВСЕ баги, найденные в продукте. Администратор СТБ должен настроить последнюю так, чтобы исключить воз- можность удаления багов пользователями СТБ. Таким образом, каждый баг, когда-либо найденный в продукте, будет иметь одно из трех упомянутых значений статуса. RESOLUTION (РЕЗОЛЮЦИЯ) Это ниспадающее меню со значениями: Not Assigned (не приписан) Assigned (приписан) Fix in Progress (баг ремонтируется) Fixed (баг отремонтирован) Build in Progress (билд на тест-машину в процессе) Verify (проведи регрессивное тестирование) Fix is Verified (ремонт был успешен) Verification Failed (ремонт был неуспешен) Can't Reproduce (не могу воспроизвести) Duplicate (дубликат) Not a bug (не баг) 3rd party bug (не наш баг) No longer applicable (поезд ушел) 236 Тестирование Дот Ком. Часть 3 Резолюция — очень важный атрибут, напрямую связанный со статусом. Если статус — это своего рода "жив", "умер", "реинкарнировался", то резолюция — это "поступил в институт", "женился", "купил машину", т.е. резолюция — это детализация статуса. Not Assigned (не приписан) Такая резолюция может быть после того, как баг занесен, но лицо, занесшее баг в СТБ, не знает, кто может этот баг зафиксировать. Assigned (приписан) К новому багу приписан держатель (owner), т.е. лицо, ответст- венное за совершение следующего действия в отношении бага в соответствии с процессом. Как мы помним, у каждого открытого бага всегда есть дер- жатель. В случае резолюции Not Assigned держателем бага является автор бага, не передавший его дальше. Итак, меняем статус на Assigned, когда передаем баг для ремонта, и выбираем имя из ниспадающего меню Assigned to. Fix in Progress (баг ремонтируется) Это значение резолюции выбирается программистом, когда он начинает ремонт бага. Держатель бага — программист. Fixed (баг отремонтирован) Это значение резолюции выбирается программистом после того, как он • отремонтировал баг и • сохранил код в CVS. Держатель бага — релиз-инженер. Build in Progress (билд на тест-машину в процессе) Это значение резолюции выбирается релиз-инженером (а иногда и билд-скриптом) после запуска на тест-машину билда с отре- монтированным кодом, т.е. Build in Progress приходит на смену Fixed. Жизнь замечательных багов 237 Здесь нужно заметить, что если даже баг найден на машине для пользователей, патч-релиз происходит только после того, как ре- монт протестирован на тест-машине. Держатель бага — релиз-инженер. Verify (проведи регрессивное тестирование) Это значение резолюции выбирается релиз-инженером (а иногда и билд-скриптом) после того, как билд на тест-машину завершен. Держатель бага — лицо, чье имя указано в Verifier. Если у вери- фаера нет возможности проверить ремонт, то он может просто выбрать другое значение Verifier так, чтобы его коллега принял груз ответственности. Fix is Verified (ремонт был успешен) Регрессивное тестирования бага состоит из двух частей, следую- щих одна за другой в таком порядке: Часть 1: проверка того, что баг был действительно починен, т.е. четко следуем инструкциям из "Описания и шагов..." для вос- произведения бага. Если функциональность работает как сле- дует, то баг действительно был починен. Часть 2: проверка того, что ремонт бага не наплодил других багов. Код — это тонкая материя, состоящая из множества взаимо- зависимых компонентов, и чем сложнее ПО, тем труднее пред- угадать, как изменение кода в одном месте отразится на рабо- те всех закоулков системы. Если программист не указывает в комментариях, какая часть ПО может быть попутно затронута ремонтом, я в зависимости от ситуации • прохожу по приоритетному флоу функциональности, код которой был отремонтирован, и/или • делаю энд-ту-энд-тест. Пример с энд-ту-энд-тестом в функциональности корзины была проблема с тем, что пользователь не мог изменить количество книг. Энд-ту-энд-тест, который бы я сделал: а) добавить в корзину книгу, б) изменить количество книг и в) произвести оплату. 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 — количество часов, которое длится совещание. Я встречал P J 'M OB очень разных квалификаций и навыков в обще- нии. Бывали даже случаи, когда я шел к своему менеджеру и про- сил его дать мне другой проект, так как не хотел работать с неким конкретным менеджером проекта. В подавляющем большинстве случаев в стартапах обязанно- сти менеджера проекта исполняют продюсеры. 244 Тестирование Дот Ком. Часть 3 Итак, обратно к "не нашему" ПО. Во многих случаях наш веб-сайт так или иначе связан с ПО, ко- торое принадлежит нашим бизнес-партнерам и ими же поддер- живается в рабочем состоянии, например это ПО для процессинга кредитных карт. Так вот если найденный баг является багом в таком ПО, то тот, кто исполняет обязанности менеджера проекта, набирает номер ответственного лица на стороне наших бизнес-партнеров и коор- динирует действия между нашей и не нашей стороной (например, нашим и не нашим программистами) по разрешению проблемы. Может, это и не баг вовсе, а недопонимание нами, как работает не наше ПО. Если же это баг, то наш партнер заносит запись о нем в собствен- ную СТБ. Далее. Если это баг, то могут быть следующие варианты: • баг имеет место быть на не нашей тест-машине, т.е. наша тест-машина "разговаривает" с их тест-машиной и/или • баг имеет место быть на не нашей машине для пользовате- лей (мы выступаем в роли пользователей), т.е. наша машина для пользователей "разговаривает" с их машиной для поль- зователей. В зависимости от того, где был найден баг в не нашем ПО и от его важности для нас, а соответственно для нашего контрагента, назначается приоритет, от которого зависит и скорость починки. Всю координацию от "А" до "Я" с нашей стороны осуществляет тот, кто исполняет обязанности менеджера проекта. Итак, если мы можем повлиять на производителей не нашего ПО и программист вернул вам баг с резолюцией 3rd party bug, вы в Assigned to выбираете имя того, кто исполняет обязанности ме- неджера проекта, и, сопровождая баг своими комментариями, делаете его держателем бага. Он со своей стороны после выясне- ния: "Кто виноват? Что делать? и Едят ли курицу руками?" — может вернуть вам баг с резолюцией Not a Bug (если это был не баг, а недопонимание того, как работает не наше ПО) либо же вернуть вам баг (путем Assigned to) с той же резолюцией — 3rd |