Часть 3.2
- Рома
- 8 апр. 2015 г.
- 15 мин. чтения
ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ
После того как баг обнаружен,
• нужно занести его в систему трэкинга багов и
• после того как он зафиксирован:
а) проверить, на самом ли деле он был зафиксирован и
б) не повредила ли починка этого бага другие части на шего ПО.
Кстати, как мы помним, а и б называются регрессивным тестированием.
Процесс, который начинается с занесения бага в систему трэкинга багов (Bug Tracking System), называется процессом трэкинга багов (Bug Tracking Procedure), и для удобства понимания всей стадии исполнения тестирования мы начнем именно с него.
СТБ — это инфраструктура, позволяющая
• создавать,
• хранить,
• просматривать и
• модифицировать информацию о багах.
Существует множество профессиональных СТБ — от бесплатной Багзиллы (Bugzilla) до многотысячедолларового тест-директора (Test Director by Segue)
Каждый баг, занесенный в СТБ, представляет собой виртуальную учетную карточку
Каждая такая карточка существует не сама по себе, а как часть процесса трэкинга багов (далее — Процесс). С каждым багом, занесенным в СТБ, начинается новый Процесс. Вопрос: Как определить, на какой стадии Процесса находится каждая конкретная карточка?
Ответ: Ничего нет проще — нужно просто посмотреть на ее атрибуты.
Одним из атрибутов является статус бага. Статус может принимать одно из трех значений:
• Open (открыт),
• Closed (закрыт) либо
• Re-open (повторно открыт).
Как фактически происходит занесение бага в СТБ? Например, так: вы
• открываете веб-браузер;
• печатаете в нем URL вашей СТБ в локальной сети и нажимаете Enter;
• после того как загрузилась страница СТБ, вводите имя пользователя и пароль;
• нажимаете на кнопку "New bug" (Новый баг);
• на веб-форме "Новый баг" заполняете поля и выбираете значения;
• нажимаете на кнопку "Submit new bug" (Занести новый баг).
Баг в зависимости от контекста будет иметь одно из следующих значений или оба значения:
• баг как отклонение фактического результата от ожидаемого результата и/или
• баг как созданная в СТБ виртуальная учетная карточка, являющаяся, по чьему-либо субъективному мнению, презентацией некой проблемы.
Атрибуты бага
BUG NUMBER (НОМЕР БАГА) Каждому новому багу СТБ автоматически присваивает уникальный, следующий по порядку номер.
SUMMARY (КРАТКОЕ ОПИСАНИЕ) Краткое описание — это максимально информативное и сжатое описание проблемы.
Если баг начинается с номера спека, то баги
• можно сортировать по колонке Summary, таким образом баги, принадлежащие к одному спеку, будут кучковаться вместе, и
• можно искать по номеру спека, используя функциональность СТБ "Поиск". Очень, кстати, удобно и вам, и программистам, и продюсерам.
DESCRIPTION AND STEPS TO REPRODUCE (ОПИСАНИЕ И ШАГИ ДЛЯ ВОСПРОИЗВЕДЕНИЯ ПРОБЛЕМЫ) Это многострочное текстовое поле. Я пользуюсь следующим форматом для заполнения этого атрибута:
Description: Полезная информация о баге: описание, комментарии, нюансы и т.д.
Steps to reproduce: Конкретные шаги для воспроизведения проблемы.
Bug: Фактический результат.
Expected: Ожидаемый результат.
Вот небольшой список наиболее часто встречающихся элементов веб-страницы, который позволит вам более четко описывать и шаги для воспроизведения багов, и шаги тест-кейсов.
-Я текст. Вещь незаменимая
-Я линк. Просто линк
Также известен как ссылка или гиперссылка. Если нажать на линк (или, по-простому, "кликнуть линк") (click link), то мы попадем
• либо на другую веб-страницу,
• либо на определенное место страницы, на которой находится линк (например, если на одной странице есть список названий глав книги (Содержание) и сами главы, то название каждой главы в Содержании может быть слинковано с началом текста главы).
Кстати:
1. Линк может быть сломан (broken link), т.е. нажимаем на линк и никуда не идем либо получаем сообщение, что страница не найдена.
2. Линк может вести не туда , куда нужно (misleading link), например, вы кликаете на линк " Контактная информация", а попадаете на страницу 'Корзина".
Для проверки сломанных линков есть прекрасный бесплатный тул, называемый Хеnи 's Link Sleuth (можете скачать его из Интернета).
-Картинка (image)
Картинки — это графические файлы (как правило, GIF либо JPG), на которые ссылается HTML-код, веб-страницы и которые через Интернет летят на жесткий диск наших ком- пьютеров. Если вы в окне браузера видите картинку, то знайте, что она сохранена на жестком диске...
Кстати: Сломанная картинка (broken image): ситуация, когда, как правило, путь к графическому файлу в HTML-коде указан неверно или путь ука- зан верно, но сам файл поврежден (corrupted/damaged) и на веб-стра- нице мы видим лишь рамку, в которой должна была быть картинка:
-Слинкованная картинка (linked image)
По сути это линк, который представлен не текстом, а картинкой. Соответственно у слинкованной картинки могут быть болезни как линков, так и картинок.
-Однострочное текстовое поле (textbox)
Однострочное текстовое поле (или просто "текст-бокс") — это один из элементов веб-формы (web form), которая может быть на веб-странице.
Для примера: веб-форма всегда является частью веб-страницы с регистрацией, когда вы вводите имя, пароль, е-мейл (и т.д.) и нажимаете кнопку "Зарегистрироваться". Все остальные элементы, перечисленные далее:
• многострочное текстовое поле;
• поле для пароля;
• радиокнопка;
• чекбокс;
• кнопка, также являются элементами веб-формы
Кстати, текстовое поле используется для введения множества видов текстовой информации: от имени пользователя до ввода текста, увиденного на кепча (от англ. captcha, читается как кэпча).
Проверка количества символов, которое может принять в себя текстовое поле, проводится в рамках тестирования интерфейса пользователя (UlTesting).
-Многострочное текстовое поле (text entry area)
используется для ввода информации, которая не умещается в однострочном текстовом поле. Например, для создания постинга на интернет-форумах под предмет сообщения (subject) отдается текстбокс, а под само сообщение — многострочное текстовое поле. Кстати, прекрасным, истинно сероящичным тестом является проверка того, умещается ли наш ввод в соответствующую колонку базы данных. Под вводом в данном случае подразумеваются данные, введенные посредством текст-бокса или многострочного текстового поля
-Поле пароля (passwordfield)
Это однострочное поле для ввода текста с тем нюансом, что каждый символ, введенный в это поле, тут же автоматически преобразуется в * (звездочку, или, по-англ. — asterisk) либо в жирную метку (bullet).
-Ниспадающее меню (pull down menu)
Ниспадающее меню дает возможность выбрать одно, и только одно, значение из списка значений меню. Наитипичнейший пример — ниспадающее меню со списком стран на веб-форме регистрации.
-Радиокнопка (radio button)
Радиокнопка, также известная под неудобоваримым именем "зависимая кнопка", — это элемент веб-формы, который позволяет выбрать одно, и только одно, значение из списка своих собратьев. Список называется группой радиокнопок, которая объединена одним названием и/или логичной принадлежностью к группе. Значения радиокнопок взаимоисключаемы, и, таким образом, кнопки взаимосвязаны.
-Чекбокс (checkbox)
Чекбокс, также известный под неудобоваримым именем "независимая кнопка", — это элемент веб-формы, который позволяет: установить галочку (check) либо убрать галочку (uncheck). Иными словами, можно соответственно: отметить чекбокс, очистить чекбокс.
-Кнопка (button)
Нажатие на кнопку является заключительным аккордом при заполнении веб-форм. Нажимая на кнопку, мы отправляем веб-форму для обработки на сервер с приложением (application server).
ATTACHMENT(ПРИЛОЖЕНИЕ)
Нет лучшей вещи при обмене информацией, чем хорошо подобранная иллюстрация, особенно наглядная иллюстрация. Наш мозг гораздо быстрее воспринимает зрительную информацию, чем текстовую, и мы, зная этот научный факт, можем организовать эффективную презентацию проблемы. Презентация может делаться, например, путем приложения снимка экрана (скриншота), на котором видна проблема.
Иногда бывают ситуации, что трудно описать проблему на родном языке, не говоря уже об иностранном. Что делаем? Прилагаем файл с иллюстрацией проблемы в поле "Описание и шаги для воспроизведения проблемы" и скромно пишем "Смотри при- ложение" (See attachment). Кстати, фраза "Смотри приложение" должна быть в поле "Описание и шаги..." в любом случае — чтобы каждый, кто просматривает занесенный вами баг, наверняка открыл и приложение.
SUBMITTED BY (АВТОР БАГА)
СТБ автоматически присваивает значение этому атрибуту. Как нетрудно догадаться, значение "Submitted by " — это нередактируемый текст с именем товарища, занесшего баг в СТБ (товарищ далее именуется автором бага). Как правило, автором бага явля- ется тестировщик.
DATE SUBMITTED (ДАТА И ВРЕМЯ ПОЯВЛЕНИЯ БАГА)
Как и в случае с Submitted by, СТБ автоматически присваивает значение этому атрибуту. Как нетрудно догадаться, значение "Date submitted" — это нередактируемый текст с датой и временем, когда баг был занесен в СТБ своим отцом — автором.
ASSIGNED TO (ДЕРЖАТЕЛЬ БАГА)
Каждый открытый баг в каждый конкретный момент имеет своего конкретного держателя (Owner). Держатель бага — это участник процесса разработки ПО, на котором лежит ответственность сделать следующий шаг на пути к закрытию бага.
ASSIGNEDBY(ИМЯ ПЕРЕДАВШЕГО БАГ)
Значение этого атрибута (как и Submitted by) является нередактируемым текстом. СТБ автоматически присваивает атрибуту Assigned by имя пользователя СТБ, который выбрал значение Assigned to. Таким образом, счастливчик, который стал Assigned to, всегда знает, кто был тем доброжелателем, который сделал его держателем бага.
VERIFIER(ИМЯ ТОГО, КТО ДОЛЖЕН ПРОВЕРИТЬ РЕМОНТ)
Это ниспадающее меню с тем же списком имен сотрудников, что и в Assigned to. Как мы помним, баг может быть занесен в СТБ любым сотрудником интернет-компании, который имеет счет в СТБ и соответст- вующую привилегию. При занесении бага значение Verifier автоматически становится равным имени автора бага.
COMPONENT(КОМПОНЕНТ)
Это ниспадающее меню со списком, как правило, функциональных частей веб-сайта. Например, этот список вполне может быть таким вот коротким и скромным: "Регистрация Поиск Корзина Оплата Другое" При занесении бага в СТБ автор бага должен выбрать компонент, тестируя который он нашел заносимый баг.
FOUNDON(ГДЕ БЫЛ НАЙДЕН БАГ)
Это ниспадающее меню, которое включает
• имена тест-сайтов, обитающих на нашей тест-машине;
• скромное слово "ZJFЈ"' (машина для пользователей);
• Spec ("Спек");
• Other ("Другое").
Немедленная польза от использования атрибута Found on заключается в том, что каждый, кто хочет воспроизвести занесенный баг, знает, где конкретно это можно сделать
VERSION FOUND (ВЕРСИЯ, В КОТОРОЙ БЫЛ НАЙДЕН БАГ)
Это ниспадающее меню с версиями веб-сайта, автор бага обязан выбрать значение, соответствующее номеру версии продукта, в которой был найден баг.
BUILD FOUND (БИЛД, В КОТОРОМ БЫЛ НАЙДЕН БАГ)
Это небольшое (примерно 10 символов) текстовое поле, куда автор бага обязан вбить номер билда, в котором был найден баг.
VERSION FIXED (ВЕРСИЯ С ПОЧИНЕННЫМ КОДОМ)
Это ниспадающее меню с версиями веб-сайта. После того как программист починил баг, он должен передать этот баг далее (релиз-инженеру), для того чтобы в итоге Verifier произвел регрессивное тестирование (у нас будет подробное объяснения процесса через 5 минут). Программист обязан выбрать номер версии, соответствующий бранчу в CVS, куда он направил отремонтированный код.
BUILD FIXED (БИДД С ПОЧИНЕННЫМ КОДОМ)
Это небольшое (например, 10 символов) текстовое поле, которое заполняется в то же время, что и Version Fixed, т.е. после починки бага и помещения починенного кода в CVS. В Build Fixed программист обязан указать номер следующего билда, который под- хватит исправленный код из CVS. Так, если
• номер последнего билда на www.main.testshop.rs равен 114,
• билд-скрипт для нового билда стартует в 16:00 и
• программист направил код в CVS в 15:30, то билд 115 должен содержать исправленный код из CVS и, следовательно, программист должен вбить в Build Fixed значение "115". Очень очевидный и очень важный момент, о которым мы уже говорили: перед началом регрессивного тестирования Verifier должен удостовериться, что версия и билд на тест-машине соответствуют значениям атрибутов Version Fixed и Build Fixed для данного бага.
COMMENTS (КОММЕНТАРИИ)
Это многострочное текстовое поле, куда любой имеющий счет в СТБ и соответствующую привилегию может занести свои ком- ментарии, пояснения, уточнения и т.д. • о баге и/или • своих действиях в отношении бага. В некоторых случаях комментарий должен быть обязательным для заполнения, например когда программист возвращает баг тестировщику, так как считает, что это вовсе не баг.
SEVERITY (СЕРЬЕЗНОСТЬ БАГА)
Форма: ниспадающее меню со значениями от О до С4 (51—4) включительно. Содержание: серьезность бага — это степень воздействия бага (magnitude of impact) на ПО, исходя из принадлежности бага к определенной технической категории.
С1— КРИТИЧЕСКИЙ
Критический системный сбой — ситуация, когда какая-то часть ПО на машине для пользователей "рушится" — например, нажимаете на кнопку "Поиск" и получаете ошибку "HTTP Error 500 Internal server error". Потеря данных (data loss) — чаще всего это происходит, когда данные:
а) не достигают базы данных либо
б) незапланированно удаляются из нее. Например: а) при регистрации е-мейл пользователя не вставляется в опреде ленную колонку определенной таблицы базы данных; б) при обновлении пользователем адреса на фронтенде старый адрес удаляется из базы данных. Проблема с безопасностью — например, когда после логина пароль виден как часть URL, так что кто-то может подсмотреть пароль и использовать его в своих корыстных целях. При современном состоянии дел в Интернете, когда 4% монетарных транзакций осуществляется мошенниками, безопасность — вещь первостепенная.
С2 — ЗНАЧИТЕЛЬНЫЙ
Веб-сайт "зависает" — одна из основных бед интернет-проектов, например, нажимаешь на кнопку "Купить", и следующая страница грузится, и грузится, и грузится... Как правило, после таких "загрузов" очень хочется попробовать веб-сайт конкурента. Баг блокирует кодирование, тестирование или использование вебсайта — ситуация, когда работа тестировщика (и/или программиста) и/или использование веб-сайта не могут быть продолжены, так как на одном из этапов появляется проблема, превентирующая дальнейшее продвижение.
Например, пользователь не может добавить кредитную карту к своему эккаунтуи, следовательно, не может ничего купить на нашем веб-сайте. Термин "блокирование" также связан с понятием "обходной путь" (workaround), а вернее, с отсутствием этого пути. Например, согласно тест кейсу нужно создать эккаунт путем использования тест-тула, но тест-тул не работает (баг в тест-туле является абсолютно легитимным багом!). Если есть возможность найти обходной путь, который разблокировал бы в данной ситуации тестирование, то баг не является блокирующим и не подходит под С2. Примером обходного пути в данном случае является создание эккаунта вручную.
СЗ — УМЕРЕННЫЙ
Функциональные проблемы (functional bugs) — под эту категорию подходят все функциональные баги, не подходящие под С1 и С2. Как правило, это простое расхождение между фактическим и ожидаемым результатами, когда все шаги тест-кейса (все этапы флоу) исполнены.
СА — КОСМЕТИЧЕСКИЙ
Косметическая проблема — баги, связанные с содержанием вебсайта (content), правописанием (spelling) и интерфейсом пользователя (User Interface).
PRIORITY (ПРИОРИТЕТ БАГА)
Форма: ниспадающее меню со значениями от Ш до П4 (Ш—4) включительно. Содержание: приоритет бага — это показатель важности бага для бизнеса компании. Кстати, многие товарищи путают приоритет и серьезность. Коренное различие между ними кроется в том, что серьезность отражает технический аспект бага, а приоритет — коммерческий. Серьезность — это категория абсолютная. Приоритет — это категория относительная.
Кроме привязки к серьезности бага на приоритет могут воздействовать следующие потенциальные либо реальные вещи:
• процент затронутых пользователей,
• денежные потери для компании,
• негативные юридические последствия для компании,
• негативные последствия для имиджа компании.
В каждой компании должны быть дефиниции приоритета багов (bug priority definitions), в которых обязательным элементом является указание сроков для починки багов (дополнительным элементом могут быть факторы, указанные выше, например процент затронутых пользователей).
Помните, что дружба дружбой, а если вы были заблокированы и из-за любви к своему программисту поставили ПЗ вместо Ш, то проблемы с невыполнением плана будут у вас, а не у него, так как это вы, а не он можете не закончить в срок исполнение тестирования.
NOTIFY LIST (СПИСОК ДЛЯ ОПОВЕЩЕНИЯ)
Это ниспадающее меню со списком алиасов всех пользователей, зарегистрированных в СТБ. Во многих случаях тестировщику необходимо, чтобы
• о факте занесения бага и
• о любом изменении в самой записи о баге знал определенный круг людей.
Оповещение происходит с помощью е-мейла, в который включаются:
• номер бага;
• статус;
• краткое описание;
• приоритет;
• серьезность бага;
• название, старое и новое значение измененного атрибута (например, кто-то занес свое мнение в комментарий);
• имя того, кто покусился изменить баг (либо занести новый баг в СТБ).
Как правило, по умолчанию
• после занесения бага е-мейл посылается автору бага и держателю бага,
• а при изменении записи о баге — автору бага, держателю бага и лицу, изменившему баг.
Таким образом, атрибут "Список для оповещения" используется автором бага либо другим заинтересованным лицом для того, чтобы е-мейлы посылались тем, кто не является реципиентом по умолчанию. Я всегда включаю в "Список для оповещения" имя продюсера, чтобы тот знал о состоянии дел, связанных с тестированием его спека.
CHANGE HISTORY (ИСТОРИЯ ИЗМЕНЕНИЙ)
Это наиважнейший, автоматически заполняемый атрибут. Суть его в том, что любое изменение бага отражается в нередактируемом многострочном текстовом поле в следующем формате:
• дата и время изменения (date and time of change);
• имя лица, изменившего баг (who changed);
• название измененного атрибута (what was changed);
• предыдущее значение атрибута (previous value);
• новое значение атрибута (new value).
Запомните, что любые действия любого лица, имеющего счет в СТБ, автоматически записываются, запись доступна для всех пользователей СТБ и не подлежит редактированию. Таким образом, можно до секунды увидеть, что конкретно, как конкретно и кем конкретно было изменено.
TYPE (ТИП БАГА)
Это ниспадающее меню со значениями:
• bug (баг),
• feature request (запрос о фича).
По умолчанию значение типа бага (типа записи) — это "баг", т.е. расхождение между фактическим и ожидаемым результатом, и 95% багов (записей) в СТБ имеет значение "баг".
Фича — это в зависимости от контекста
• функциональность либо
• характеристика (или свойство) компонента кода, интерфейса, базы данных и пр.
Например Значение "функциональность" работает, если мы говорим о кепча. Значение "характеристика" работает, если мы говорим об оптимизации кода с целью улучшения перформанса (скорости работы сайта).
Баг с типом Feature request заносится в СТБ с именем продюсера или программиста в Assigned to, когда у вас родилась идея об улучшении некой существующей фича или о новой фича.
Значение типа Feature request также используется в баге, служащем основанием для патч-релиза, в случае, когда появилась необходимость в срочном изменении кода на машине для пользователей и это изменение не связано с багом (как отклонением фактического от ожидаемого).
STATUS (СТАТУС)
Это ниспадающее меню со значениями:
• Open (Открыт),
• Closed (Закрыт),
• Re-Open (Повторно открыт).
Значение Open присваивается багу автоматически при занесении бага.
Закрыть баг можно только при соответствующей резолюции (об этом через минуту). Значение Re-Open выбирается тестировщиком, когда он возрождает к жизни закрытый баг.
• ВСЕ найденные баги должны заноситься в СТБ. Исключений быть не может. Ваша работа как тестировщика — искать баги. Единственный и неповторимый результат вашей работы — баг, занесенный в СТБ. Умные программисты никогда на вас не обидятся, так как качество их работы измеряется не количеством багов, ими допущенных, а скоростью, с которой они эти баги чинят (почти по Глебу Жеглову);
• занесенные в СТБ баги НИКОГДА не удаляются из СТБ. Чтобы ни случилось, пока живет компания, ее СТБ включает ВСЕ баги, найденные в продукте. Администратор СТБ должен настроить последнюю так, чтобы исключить возможность удаления багов пользователями СТБ.
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 (поезд ушел)
Резолюция — очень важный атрибут, напрямую связанный со статусом. Резолюция — это детализация статуса.
Not Assigned (не приписан)
Такая резолюция может быть после того, как баг занесен, но лицо, занесшее баг в СТБ, не знает, кто может этот баг зафиксировать.
Assigned (приписан)
К новому багу приписан держатель (owner), т.е. лицо, ответственное за совершение следующего действия в отношении бага в соответствии с процессом. Как мы помним, у каждого открытого бага всегда есть держатель.
Fix in Progress (баг ремонтируется)
Это значение резолюции выбирается программистом, когда он начинает ремонт бага. Держатель бага — программист.
Fixed (баг отремонтирован)
Это значение резолюции выбирается программистом после того, как он
• отремонтировал баг и
• сохранил код в CVS. Держатель бага — релиз-инженер.
Build in Progress (билд на тест-машину в процессе)
Это значение резолюции выбирается релиз-инженером (а иногда и билд-скриптом) после запуска на тест-машину билда с отремонтированным кодом, т.е. Build in Progress приходит на смену Fixed. Здесь нужно заметить, что если даже баг найден на машине для пользователей, патч-релиз происходит только после того, как ремонт протестирован на тест-машине. Держатель бага — релиз-инженер.
Verify (проведи регрессивное тестирование)
Это значение резолюции выбирается релиз-инженером (а иногда и билд-скриптом) после того, как билд на тест-машину завершен. Держатель бага — лицо, чье имя указано в Verifier. Если у верифаера нет возможности проверить ремонт, то он может просто выбрать другое значение Verifier так, чтобы его коллега принял груз ответственности.
Fix is Verified (ремонт был успешен)
Регрессивное тестирования бага состоит из двух частей, следующих одна за другой в таком порядке:
Часть 1: проверка того, что баг был действительно починен, т.е. четко следуем инструкциям из "Описания и шагов..." для воспроизведения бага. Если функциональность работает как следует, то баг действительно был починен.
Часть 2: проверка того, что ремонт бага не наплодил других багов. Код — это тонкая материя, состоящая из множества взаимозависимых компонентов, и чем сложнее ПО, тем труднее предугадать, как изменение кода в одном месте отразится на работе всех закоулков системы. Если программист не указывает в комментариях, какая часть ПО может быть попутно затронута ремонтом, я в зависимости от ситуации
• прохожу по приоритетному флоу функциональности, код которой был отремонтирован, и/или
• делаю энд-ту-энд-тест.
Verification Failed (ремонт был неуспешен)
Если первая часть регрессивного тестирования показала неуспешность ремонта, т.е. баг все еще существует в коде, то мы не делаем второй части, а просто выбираем это значение резолюции, после чего держателем бага становится программист, который починил код
Can Ч Reproduce (не могу воспроизвести)
Эта неприятная для тестировщика резолюция выбирается программистом после того, как перед починкой кода он пытается воспроизвести проблему и не может сделать этого. Как правило, Can 7 Reproduce имеет место в следующих случаях:
• "Описание и шаги..." содержат неполную, неверную или нечеткую информацию о том, как воспроизвести баг, и/или
• бага нет, т.е. тестировщик принял за баг правильно рабо- тающий код.
Лучшим средством превентирования подобных вещей является правило: "Перед тем как занести новый баг, воспроизведи его еще раз".
Duplicate (дубликат)
Эта резолюция выбирается после того, как повторный баг был занесен СТБ для той же проблемы.
Not a bug (не баг)
Это значение резолюции присваивается, как правило, программистом, когда возникает ситуация "it's not a bug, it's a feature " ("это не баг, а фича"), т.е. тестировщик принял за баг то, что, по мнению программиста, работает правильно. Когда возникают подобные ситуации? Например, когда тестировщик создал тест-кейсы, руководствуясь спеком, а програм мист создал код, руководствуясь чем-то иным.
3rd party bug (не наш баг)
Во всех интернет-компаниях уже используют ПО, написанное другими софтверным компаниями, например интерпретатор для любимого мною языка Python. Допустим, что я нахожу баг и заношу его в СТБ. Программист начинает поиск причины бага и видит, что его код работает чики-пики и корень зла находится в "не нашем" ПО, которое каким-либо образом связано с нашим кодом. Что делает программист? Правильно — возвращает мне баг с резолюцией 3rd party bug. Что может быть дальше?
Вариант 1: мы не можем повлиять на производителей "не нашего'" ПО так, чтобы они зафиксировали свою проблему (которая стала нашим багом). Например, если проблема была в интерпретаторе Python, то един- ственное, что мы можем сделать, — это найти обходной путь (workaround). Для того чтобы программист начал искать такой путь, мы должны оправдать его усилия тем, что закроем баг с резолюцией 3rd party bug и занесем новый баг, над которым он и станет работать. Важный момент: этот новый баг будет с типом "Feature Request".
Вариант 2: мы можем повлиять на производителей "не нашего'" ПО так, чтобы они зафиксировали свою проблему (которая стала нашим багом).
Менеджер проекта — это первый и главный контакт, который должен быть в курсе событий, знать состояние дел и знать, кто за что отвечает, чтобы быстро и точно переадресовать проблему тому, кто ее может решить.
No longer applicable (поезд ушел)
Такое значение резолюции присваивается багу, который раньше действительно был багом, но теперь по какой-то причине таковым не является.
Процесс трэкинга багов
Давайте сделаем так:
• сначала рассмотрим процесс концептуально, затем
• привяжем к каждой его стадии наши атрибуты (детальное рассмотрение процесса), затем
• приведем конкретный пример.
-Концептуальное рассмотрение процесса трэкинга багов
Задача 1: После того как мы нашли проблему в ПО, заносим новый баг.
Задача 2: Программист получает баг, старается понять, в чем проблема, и если это действительно баг, то
Задача 3: Программист начинает ремонт.
Задача 4: После того как ремонт закончен, программист должен сделать checkin кода в CVS.
Задача 5: Релиз-инженер запускает новый билд, чтобы отремонтированный код пришел из CVS на тест-машину.
Задача 6: Тестировщик проводит регрессивное тестирование, и если починка НЕ удалась, то
Задача 7: Баг возвращается программисту на но- вый ремонт. Если же починка удалась, то
Задача 8: Баг закрывается. Goodbye my love, Goodbye.
Идем обратно к развилке после задачи 2. Допустим, программист не считает, что зарапортованная ситуация является багом. Тогда он:
Задача 9: Возвращает баг.
Задача 10: Тестировщик старается понять свою ошибку, и если ошибка имела место и баг соответственно места не имел, то
Задача 8: Баг закрывается. Если же тестировщик считает, что это все-таки баг, то баг отправляется обратно программисту.
Задача 2: Программист снова пытается понять, баг ли это. И т.д.
Bình luận