Что такое система трэкинга багов
Важная оговорка: нет двух интернет-компаний, у которых процесс трэкинга багов и все нюансы системы трэкинга багов были бы идентичны. Каждый, как известно, извращается как хочет. Моя цель— развить ваше понимание предмета так, чтобы
205
|
|
Жизнь замечательных багов
207
вы со спокойной улыбкой мастера смогли адаптировать полученные знания к любым процессам и системам, которые встретятся вам на пути.
Забудем о тестировании ПО.
Допустим, мы совершаем тест-драйв на автомобиле, который собираемся купить. Проверяем ускорение, вхождение в поворот, удобство панели управления и сотню других важных вещей. После этого садимся за стол и записываем вещи, которые обманули ожидания (т.е. баги), на пронумерованные страницы новой тетради в клеточку. Один баг на одну страницу.
Например
на странице под номером 1 пишем: "Неудобно пользоваться навигационной системой";
на странице под номером 2 пишем: "Задержка в ускорении после нажатия на педаль акселератора"; на странице под номером 3 пишем: "Слишком маленький багажник".
Наша ни в чем не повинная тетрадь на самом деле является не только выброшенными на ветер деньгами, но и простейшей версией того, что называется системой трэкинга багов (СТБ).
Вспомним о тестировании. Опять же на примитивном уровне СТБ может представлять собой простой текстовый файл с записями о багах, который лежит на интранете и доступен участникам цикла разработки ПО.
|
|
|
Итак, концептуально СТБ— это инфраструктура, позволяющая
• создавать,
• хранить,
• просматриватьи
• модифицировать
Информацию о багах.
Существует множество профессиональных СТБ — от бесплатной Багзиллы (Bugzilla) до многотысячедолларового тест-директора (Test Director by Segue), и естественно, что интернет-компании используют для трэкинга багов не тетрадки или текстовые файлы, а именно специальное ПО, непосредственно созданное для трэкинга багов. О таком ПО и процессе трэкинга багов мы и поговорим сегодня.
Каждый баг, занесенный в СТБ, представляет собой виртуальную учетную карточку
208
Тестирование Дот Ком. Часть 3
Каждая такая карточка существует не сама по себе, а как часть процесса трэкинга багов (далее — Процесс).
С каждым багом, занесенным в СТБ, начинается новый Процесс.
Вопрос:Как определить, на какой стадии Процесса находится каждая конкретная карточка?
Ответ:Ничего нет проще — нужно просто посмотреть на ее атрибуты.
Пример
Одним из атрибутов является статус бага. Статус может принимать одно из трех значений:
• Open (открыт),
• Closed (закрыт) либо
• Re-open (повторно открыт).
Пример Процесса
|
|
|
После того как баг заносится в СТБ, его статус автоматически становится "Open"; после того как баг зафиксирован и регрессивное тестирование подтвердило успех починки, мы меняем статус на "Closed"; если же тот же баг, после того как мы его закрыли, был найден снова, то мы меняем "Closed" на "Re-Open".
Важно понять, что Процесскак формальный свод правил первичени такой зверь, как СТБ, приобретается именно как инструмент для материализацииПроцесса.
Другими словами, после инсталляции ответственный товарищ настраивает СТБ в соответствии с процессом, выбранным компанией, а не наоборот.
В примере со статусом мы взглянули на процесс с высоты птичьего полета. Опустимся же на землю и увидим все подробности.
Допустим, мы нашли баг. Сам факт нахождения бага, даже если это критический дефект, не имеет никакого значения и веса, пока вы не сообщили об этом баге. Два вопроса:
Комусообщить? Каксообщить?
Кому?Программисту, если это баг кода, либо продюсеру, если это баг спека.
Как?Здесь есть много путей: можно позвонить, послать е-мейл, сказать пару ласковых при личной встрече и т.д.
Жизнь замечательных багов
209
Стандартный путь, принятый в софтверных компаниях, — это занести баг в СТБ.
|
|
|
Таким образом, одной из основных функций СТБ является обеспечение коммуникациимежду участниками Процесса.
Как фактически происходит занесение бага в СТБ? Например, так: вы
• открываете веб-браузер;
• печатаете в нем URL вашей СТБ в локальной сети и нажимаете Enter;
• после того как загрузилась страница СТБ, вводите имя пользователя и пароль;
• нажимаете на кнопку "New bug" (Новый баг);
• на веб-форме "Новый баг" заполняете поля и выбираете значения;
• нажимаете на кнопку "Submit new bug" (Занести новый баг).
Все очень просто.
Кстати, отныне баг в зависимости от контекста будет иметь одно из следующих значений или оба значения:
• баг как отклонение фактического результата от ожидаемого результата и/или
• баг как созданная в СТБ виртуальная учетная карточка, являющаяся, по чьему-либо субъективному мнению, презентацией некой проблемы.
В чем разница, спросите вы. Отвечаю: проблема, занесенная в СТБ, может и не являться багом, например господин, опрометчиво занесший баг в СТБ, неправильно понял спек.
Это была ненавязчивая вводная часть, и настоящее веселье только начинается.
Атрибуты бага
BUG NUMBER (НОМЕР БАГА)
Каждому новому багу СТБ автоматически присваивает уникальный, следующий по порядку номер. Например, подходите вы к программисту и спрашиваете: "Слушай, браза, как там 1232 поживает?"
|
|
|
210
Тестирование Дот Ком. Часть 3
SUMMARY (КРАТКОЕ ОПИСАНИЕ)
Краткое описание — это максимально информативное и сжатое описаниепроблемы.
Как правило, текстовое поле для краткого описания не превышает 100 символов и в эти 100 символов (включая пробелы) нужно уместить информацию, достаточную для понимания сути проблемы.
Кстати,
то, как тестировщик формулирует краткое описание, наглядно говорит о его профессионализме.
Пример самого плохого Summary
"Ничего не работает". За такое Summary раньше били по голове канделябром, и хотя сейчас времена другие, но все равно, пожалуйста, никогда, никогда не пишите в кратком описании ничего подобного.
Почему поле для краткого описания такое короткое? Потому что баги, занесенные в СТБ, выглядят примерно так, списком, на значения которого можно кликнуть мышкой и получить полную информацию по конкретным багам:
| Bug | Summary | |
| 1 | Неверное значение колонки result таблицы ее transaction для | VISA |
| 2 | Неверное значение баланса Switch после покупки | |
| 3 | Ошибка при логине: "SQL Error" | |
| 4 | Корзина не сохраняет выбранные книги |
Если есть номер спека, то можно давать краткое описание в таком формате:
<номер спека> : <само краткое описание>, например: 7422: неверное значение баланса Switch после покупки.
Если баг начинается с номера спека, то баги
• можно сортировать по колонке Summary, таким образом баги, принадлежащие к одному спеку, будут кучковаться вместе, и
• можно искать по номеру спека, используя функциональность СТБ "Поиск". Очень, кстати, удобно и вам, и программистам, и продюсерам.
Жизнь замечательных багов
211
Итак, в кратком описании сжато и информативно излагаем суть проблемы.
DESCRIPTION AND STEPS TO REPRODUCE
(ОПИСАНИЕ И ШАГИ ДЛЯ ВОСПРОИЗВЕДЕНИЯ ПРОБЛЕМЫ)
Это многострочное текстовое поле. Я пользуюсь следующим форматом для заполнения этого атрибута:
Description:
Полезная информация о баге: описание, комментарии, нюансы и т.д.
Steps to reproduce:
Конкретные шаги для воспроизведения проблемы.
Bug: Фактический результат. Expected: Ожидаемый результат.
Пример для бага 1
Description:
При оплате картой VISA в колонке result таблицы cc_transaction в базе данных записывается неверное значение.
Используйте следующую информацию для воспроизведения проблемы:
Эккаунт: testuser1/pa$$w0rd
Наименование товара: book117
Данные карты:
Номер: 9999-5148-2222-1277
Окончание действия: 12/07
CW2: 778
SQL1: select result from cc_transaction where id = <номер заказа>;
Steps to reproduce:
1. Открой www.main.testshop.rs
2. Введи имя пользователя.
3. Введи пароль.
4. Нажми кнопку "Войти".
5. Введи наименование товара в поле поиска.
6. Нажми кнопку "Найти".
7. Кликни линк "Добавить в корзину".
8. Кликни линк "Корзина".
9. Кликни линк "Оплатить".
10. Выбери вид карты.
11. Введи номер карты.
12. Введи срок окончания действия.
13. Введи CW2.
14. Нажми кнопку "Завершить заказ".
15. Запиши номер заказа.
16. Запроси базу данных с SQL1.
Bug: 20. Expected: 10.
212
Тестирование Дот Ком. Часть 3
Важный момент:
Steps to reproduce могут использоваться для воспроизведения проблемы и программистами, и тестировщиками, и продюсерами. В тест-кейсах можно допустить употребление принятых в отделе качества сокращений и акронимов, а также ссылок к внешним документам: коллеги-тестировщики поймут и простят, но многие очевидные для тестировщика вещи совершенно неочевидны, например, для продюсера. Поэтому, пожалуйста, пишите четкие и подробные шаги, чтобы ваши коллеги из других отделов без проблем воспроизводили баги и нахваливали ваши описания.
Вот небольшой список наиболее часто встречающихся элементов веб-страницы,который позволит вам более четко описывать и шаги для воспроизведения багов, и шаги тест-кейсов.
| Я текст. Вещь незаменимая | |
| Текст (text) | |
| Не знаю, какое описание дать здесь. Текст есть текст. | |
| Кстати: | |
| 1. Текст может быть неверного содержания* (противоречащий 2. Нужного текста может не быть вовсе*. 3. Может быть неправильным шрифт (font), цвет (color), размер | |
| Естественно, что проблемы неверного содержания элемента или полного его отсутствия могут быть не только у текста, но и у всех остальных элементов. | |
| Я линк. Просто линк |
| Линк(link) |
| Также известен как ссылка или гиперссылка. Если нажать на линк |
| (или, по-простому, "кликнуть линк")(click link), то мы попадем |
| • либо на другую веб-страницу, |
| • либо на определенное место страницы, на которой находится |
| линк (например, если на одной странице есть список названий |
| глав книги (Содержание) и сами главы, то название каждой главы |
| в Содержании может быть слинковано с началом текста главы). |
Жизнь замечательных багов
213
| Кстати: | ||
| 1. Линк может | быть сломан | (broken link), т.е. нажимаем на линк |
| и никуда не | идем либо получаем сообщение, что страница не | |
| найдена. | ||
| 2. Линк может | вести не туда | , куда нужно (misleading link), напри- |
| мер, вы кликаете на линк " | Контактная информация", а попадаете | |
| на страницу | 'Корзина". | |
| Для проверки сломанных линков есть прекрасный бесплатный тул, | ||
| называемый Хепи 's Link Sleuth (можете скачать его из Интернета). | ||
Картинка(image)
Ну, куда же мы без них. Картинки — это графические файлы (как правило, GIF либо JPG), на которые ссылается HTML-код, веб-страницы и которые через Интернет летят на жесткий диск наших компьютеров. Если вы в окне браузера видите картинку, то знайте, что она сохранена на жестком диске...
Кстати:
Сломанная картинка (broken image): ситуация, когда, как правило, путь к графическому файлу в HTML-коде указан неверно или путь указан верно, но сам файл поврежден (corrupted/damaged) и на веб-странице мы видим лишь рамку, в которой должна была быть картинка:
Слинкованная картинка(linked image)
По сути это линк, который представлен не текстом, а картинкой. Соответственно у слинкованной картинки могут быть болезни как линков, так и картинок.
214
Тестирование Дот Ком. Часть 3
| Я имя текстового поля: | А я текст внутри текстового поля |
Однострочное текстовое поле(textbox)
Однострочное текстовое поле (или просто "текст-бокс") — это один из элементов веб-формы (web form), которая может быть на веб-странице. Для примера: веб-форма всегда является частью веб-страницы с регистрацией, когда вы вводите имя, пароль, е-мейл (и т.д.) и нажимаете кнопку "Зарегистрироваться". Все остальные элементы, перечисленные далее:
• многострочное текстовое поле;
• поле для пароля;
• радиокнопка;
• чекбокс;
• кнопка,
также являются элементами веб-формы.
Кстати,
текстовое поле используется для введения множества видов текстовой информации: от имени пользователя до ввода текста, увиденного на кепча (от англ. captcha, читается как кэпча).
Веб-индустрия использует кепча (которое является динамически сгенерированной картинкой) для того, чтобы превентировать автоматические программы от использования веб-сайта. Идея в том, что человек может распознать символы, изображенные на кепча, а компьютер — нет. Вот пример кепча — страница регистрации на Yahoo!. На ней изображено (буквы латинские): рЗт4ак:
|
|
|
|
| More info |
Verify Your Registration
*Enter the code shown:
This helps Yahoo! prevent automated registration.
В отношении проблем:
Размер текст-бокса (MAXLENGTH), т.е. максимальное количество символов, которое можно ввести в текстовое поле, может быть больше или меньше, чем указано в спецификации.
Проверка количества символов, которое может принять в себя текстовое поле, проводится в рамках тестирования интерфейса пользователя (UlTesting).
Жизнь замечательных багов
215
| Я имя многострочного текстового поля: |
| А я текст внутри многострочного текстового поля. Такие вот дела. |
Многострочное текстовое поле(text entry area)
используется для ввода информации, которая не умещается в однострочном текстовом поле. Например, для создания постинга на интернет-форумах под предмет сообщения (subject) отдается текст-бокс, а под само сообщение — многострочное текстовое поле.
Кстати,
прекрасным, истинно сероящичным тестом является проверка того, умещается ли наш ввод в соответствующую колонку базы данных. Под вводом в данном случае подразумеваются данные, введенные посредством текст-бокса или многострочного текстового поля.
Пример
При регистрации наш новый пользователь заполняет соответствующую веб-форму и нажимает на кнопку "Зарегистрироваться".
Некий файл (например, написанный на языке Python и живущий на сервере с приложением) трансформирует эту форму в язык, понятный базе данных (язык называется SQL — Structured Query Language, произносится как "эс-кью-эл"), и создает новую строку (record) в таблице, называемой, например, USER ADDRESS (адрес пользователя).
Допустим, что при создании таблицы USERADDRESS программист ошибочно указал максимальный размер колонки ADDRESS1 в 7 символов (VARCHAR (7)) вместо 37, положенных по спеку. Это приведет к тому, что при создании новой строки в USERADDRESS данные, включаемые в колонку ADDRESS1, будут ограничены 7 символами, а 8-й и прочие символы будут отсечены (truncated) (кстати, пробел — это тоже символ):
USER_ADDRESS
| RECORD ID | ADDRESS 1 | ADDRESS2 | CITY | STATE | Country | ZIP CODE |
| 1 | 12 49th | Apt. 2 | San Francisco | CA | USA | 94118 |
| 2 | 121 Ano | Moscow | Russia | 117602 | ||
| 3 | 221b Ba | London | UK | NW1 | ||
| 4 | 82 Boul | Paris | France | 75018 |
Что делаем? Правильно, заносим баг, и, после того как баг зафиксирован и проверен нами, адреса, хвосты которых были отсечены, уже выглядят так:
216
Тестирование Дот Ком. Часть 3
USER_ADDRESS
| RECORDJD | ADDRESS 1 | ADDRESS2 | CITY | STATE | Country | ZIP CODE |
| 1 | 12 49th Avenue | Apt. 2 | San Francisco | CA | USA | 94118 |
| 2 | 121 Anokhin Avenue | Moscow | Russia | 117602 | ||
| 3 | 221b Baker Street | London | UK | NW1 | ||
| 4 | 82 Boulevard de Clichy | Paris | France | 75018 |
Кстати, хорошей идеей для ввода при тестировании является описательный ввод, например, в текст-бокс Адрес 1 (данные которого идут в ADDRESS1) нужно было бы ввести не милую сердцу 82 Boulevard de Clichy, а строку
"а запятая является 38-м символом, 11111111111"
и затем проверить базу данных.
Если ADDRESS 1 содержит строку
"а запятая является 38-м символом", —
ни символом больше, ни символом меньше, то ADDRESS 1 вмещает ровно 37 символов и код ведет себя согласно спеку. В любом ином случае (36 или меньше символов либо 38 или больше символов) у нас есть баг.
| Я имя поля для пароля: | ******* |
Поле пароля(passwordfield)
Это однострочное поле для ввода текста с тем нюансом, что каждый символ, введенный в это поле, тут же автоматически преобразуется в * (звездочку, или, по-англ. — asterisk) либо в жирную метку (bullet).
Преобразование в звездочки (или буллеты) сделано для того, чтобы какой-либо добрый, сердечный человек не подсмотрел ваш пароль и не очистил ваш, например, банковский эккаунт.
Кстати,
важной вещью в отношении пароля я&чяется профессиональная этика, согласно которой нужно демонстративноотворачивать голову на 90 градусов в другую сторону от клавиатуры, если кто-то вводит пароль. Смотреть на клавиатуру, когда кто-либо вводит пароль, так же неприлично, как сказать о блефе, после того как вы выиграли партию в покер и карты уже перемешаны.
Жизнь замечательных багов
217
Еще одна мысль
во множестве западных компаний каждый ваш удар по клавишам клавиатуры (keystroke) невидимо для вас запечатлевается в текстовом файле (log), который является собственностью компании и который, если будет нужно (естественно, не во благо вам), будет поднят вашим менеджером и проанализирован.
Впрочем, так же могут быть подняты и проанализированы скриншоты (снимок изображения на экране вашего монитора), которые делаются с определенным интервалом (например, 60 секунд) и также являются собственностью вашего работодателя.
Кстати,
если уж заговорили об осторожности: в США недавно был создан судебный прецедент, согласно которому все содержимое папок е-мейла работника является собственностью работодателя, на это содержимое не распространяются законы о защите частной жизни (privacy), и соответственно работодатель может спокойно просматривать всю вашу корреспонденцию, посланную с рабочего е-мейла или полученную на него.
Так что не теряйте бдительности, товарищи, блоги и личная переписка могут подождать до вечера.
В отношении проблем:
размер поля пароля (MAXLENGTH), т.е. максимальное количество символов, которые можно ввести в него, может быть больше или меньше, чем указано в спецификации.
| Я имяниспадающего меню: | Я первое значение списка V |
|
| Я первое значение списка | ||
| Я второе значение списка Я третье значение списка | ||
| Ниспадающее меню(pull down menu) Ниспадающее меню дает возможность выбрать одно, и только одно, значение из списка значений меню. Наитипичнейший пример — ниспадающее меню со списком стран на веб-форме регистрации. | ||
218
Тестирование Дот Ком. Часть 3
|
|
Я имя радиокнопки:
И я тоже имя радиокнопки:
либо
Я имярадиокнопки:
И ятоже имярадиокнопки:
Радиокнопка (radio button)
Радиокнопка, также известная под неудобоваримым именем "зависимая кнопка", — это элемент веб-формы, который позволяет выбрать одно, и только одно, значение из списка своих собратьев. Список называется группой радиокнопок, которая объединена одним названием и/или логичной принадлежностью к группе. Значения радиокнопок взаимоисключаемы, и, таким образом, кнопки взаимосвязаны.
Кстати,
согласно www.multitran.ru английское название выбрано по аналогии с кнопками выбора диапазона волн радиоприемника, когда в каждый текущий момент может быть выбрана только одна волна.
Пример
возьмем группу под названием "Пол". Может быть либо так:
|
|
Пол: Муж.
|
|
Жен.
либо этак:
Пол: Муж.
|
|
|
|
Жен.
В отношении терминологии.
Можно выбрать (select) радиокнопку:
в первом случае — «выбрали радиокнопку "Муж."», во втором случае — «выбрали радиокнопку "Жен."».
Радиокнопка может существовать только как элемент группы (2 и больше) взаимоисключаемых собратьев, в случаях же когда элемент один или элементы взаимонезависимы, используется чекбокс.
Жизнь замечательных багов
219
|
|
Я имя чекбокса (кстати, мой чекбокс не отмечен)
И я имя чекбокса (мой чекбокс отмечен):
Я тоже имя чекбокса (мой чек-бокс отмечен):
Чекбокс(checkbox)
Чекбокс, также известный под неудобоваримым именем "независимая кнопка", — это элемент веб-формы, который позволяет:
установить галочку (check) либо убрать галочку (uncheck).
Иными словами, можно соответственно:
отметить чекбокс, очистить чекбокс.
Чекбоксы, как и радиокнопки, могут быть сгруппированы под одним именем (в примере ниже именем является "Причины закрытия эккаунта"), но чекбоксы, как правило, независимы друг от друга.
"Как правило ", так как иногда веб-мастера предусматривают (с помощью JavaScript) взаимосвязь между чекбоксами.
Вот веб-форма опросника при закрытии счета:
|
|
Причины закрытия эккаунта:
Сайт работает слишком медленно Неудовлетворительная служба поддержки Сбои в работе веб-сайта Ограниченный выбор книг Проблемы с доставкой Другое:
220 Тестирование Дот Ком. Часть 3
| Я имякнопки!!! |
| Кнопка(button) |
| Нажатие на кнопку является заключительным аккордом при заполнении веб-форм. Нажимая на кнопку, мы отправляем веб-форму для обработки на сервер с приложением (application server). |
| Кстати, |
| в большинстве случаев наличие ошибок при заполнении формы (например, обязательное для заполнения текстовое поле "Имя " пустое) |
| проверяется не на сервере с приложением, а на компьютере пользователя. |
| Это делается путем кода JavaScript, являющегося частью HTML-страницы с веб-формой, и в случае ошибки в заполнении формы |
| выдается сообщение об ошибке, веб-форма не посылается на сервер с приложением. |
| Если неизвестно название кнопки, то при написании тест-кейсов просто напишите "отправьте форму"("submit the form " или просто "submit"). |
ATTACHMENT (ПРИЛОЖЕНИЕ)
Нет лучшей вещи при обмене информацией, чем хорошо подобранная иллюстрация, особенно наглядная иллюстрация. Наш мозг гораздо быстрее воспринимает зрительную информацию, чем текстовую, и мы, зная этот научный факт, можем организовать эффективную презентацию проблемы. Презентация может делаться, например, путем приложения снимка экрана (скриншота), на котором видна проблема. Вот самый технически элементарный и повсеместно распространенный способ для собственноручного изготовления скриншота:
а. На клавиатуре нажимаем кнопку PrtScrn.
б. Открываем стандартную программу Виндоуз, Paint.
в. Нажимаем Ctrl+v.
г. Сохраняем графический файл (с расширением Jpeg или .gift.
д. Прилагаем его к багу.
Кстати, как Paint, так и другие графические редакторы позволяют обвести, например, красным цветом место на скриншоте, где видна проблема (например, группу радиокнопок, которые можно выбрать одновременно). В общем большое поле для творчества.
Жизнь замечательных багов
221
Естественно, что приложением может быть не только наглядная иллюстрация в виде графического файла, но и любые другие файлы, которые помогут программисту быстрее и точнее понять суть проблемы.
Иногда бывают ситуации, что трудно описать проблему на родном языке, не говоря уже об иностранном. Что делаем? Прилагаем файл с иллюстрацией проблемы в поле "Описание и шаги для воспроизведения проблемы" и скромно пишем "Смотри приложение" (See attachment).
Кстати, фраза "Смотри приложение" должна быть в поле "Описание и шаги..." в любом случае — чтобы каждый, кто просматривает занесенный вами баг, наверняка открыл и приложение.
SUBMITTED BY (АВТОР БАГА)
СТБ автоматически присваивает значение этому атрибуту. Как нетрудно догадаться, значение "Submitted by " — это нередакти-руемый текст с именем товарища, занесшего баг в СТБ (товарищ далее именуется автором бага). Как правило, автором бага является тестировщик.
DATE SUBMITTED (ДАТА И ВРЕМЯ ПОЯВЛЕНИЯ БАГА)
Как и в случае с Submitted by, СТБ автоматически присваивает значение этому атрибуту. Как нетрудно догадаться, значение "Date submitted" — это нередактируемый текст с датой и временем, когда баг был занесен в СТБ своим отцом — автором.
ASSIGNED TO (ДЕРЖАТЕЛЬ БАГА)
Каждый открытый баг в каждый конкретный момент имеет своего конкретного держателя(Owner). Держатель бага — это участник процесса разработки ПО, на котором лежит ответственность сделать следующий шаг на пути к закрытию бага. Варианты следующего шага определяются процессом.
Когда баг заносится в СТБ, то автор бага обязательно должен выбрать имя из списка ниспадающего меню "Assigned to " (СТБ выдаст ошибку, если имя не выбрано). Список "Assigned to " состоит из имен всех пользователей, кто имеет эккаунты в СТБ. Например, мое имя пользователя в СТБ может выглядеть как г savin.
222
Тестирование Дот Ком. Часть 3
Кстати, счета в СТБ открывает администратор СТБ, который, как правило, является вашим коллегой-тестировщиком, корпящим в соседнем отсеке по другую сторону серой стенки, украшенной постером с силовой подачей Марии Шараповой.
Если автор бага
• не знает, кто из программистов должен ремонтировать этот баг, или
• вообще не знает, что ему делать с этим багом,
то он просто выбирает из "Assigned to " самое родное и близкое, что он может там найти, — свое имя.
В каждой интернет-компании на интранете должна быть страничка "Кто за что ответствен"(Who does What). На этой страничке должны быть перечислены:
• компоненты веб-сайта (те же, что и в атрибуте "Компонент", о нем чуть позже);
• программисты, которые отвечают за эти компоненты;
• продюсеры, которые отвечают за эти компоненты.
Пример
| Компонент | Программист | Продюсер |
| Регистрация | Н. Гусев | С. Попов |
| Поиск | Р. Буйнов | А. Ключникофф, А. Зубков |
| Корзина | Ю. Тимофеев, И. Николаев | В. Жабров |
| Оплата | О. Столяров | В. Новоселов |
Нужно, чтобы эта страничка постоянноподдерживалась, например, менеджерами программистов и продюсеров, чтобы отражать текущее состояние компонентов и ответственных лиц:
если в компании 3 человека, сидящие в одном закутке 4x3 метра, то каждый примерно знает, что делают двое других. Если же компания растет и развивается, работники приходят, переводятся с участка на участок, уходят, функциональности появляются, модифицируются, исчезают... в общем перемены бьют ключом, то наличие централизованного источника информации о программистах и продюсерах — собственниках функцио-нальностей является наиудобнейшей и наиполезнейшей вещью (хотя бы для того, чтобы быстро и правильно выбрать имя из "Assigned to ").
Жизнь замечательных багов 223
Кстати, автором бага может быть не только тестировщик. Любой пользователь СТБ, имеющий право (privilege) на занесение багов в СТБ, может быть автором бага. Технически права даруются (как, впрочем, и отнимаются) администратором СТБ.
Кстати, выражение "занести баг" по-аглицки звучит как "file a bug" или "reporta bug".
Кстати, программисты часто заносят баги против своего же кода. Это не мазохизм, а холодный расчет, так как
• с одной стороны, сохранять баги в СТБ просто удобно, а
• с другой — программист должен тратить время на ремонт бага, и баг, занесенный в СТБ, оправдывает такую трату в глазах начальства, коллег и семьи.
Кстати, программисты любят играть багом в пинг-понг, меняя значение Assigned to на имена друг друга, говоря таким образом: "Это, дорогой, не мой, а твой баг", "Нет, я думаю, что это как раз твой баг", "Я не уверен, что ты прав. Этот баг все-таки твой" и т.д. Результатом таких игр является задержка в фиксировании бага.
Небольшой нюанс. Люди приходят в интернет-компанию и уходят из нее. Когда они приходят, администратор СТБ создает им счета, а когда они уходят, то эти счета НИКОГДА не удаляются: администратор СТБ просто маркирует счет бывшего коллеги как недействительный, т.е. им нельзя больше пользоваться. При этом имя пользователя СТБ в списке пользователей СТБ остается. Принцип неудаления нужен для сохранения данных, связанных с занесенными багами.
ASSIGNED BY (ИМЯ ПЕРЕДАВШЕГО БАГ)
Значение этого атрибута (как и Submitted by) является нередактируе-мым текстом. СТБ автоматически присваивает атрибуту Assigned by имя пользователя СТБ, который выбрал значение Assigned to. Таким образом, счастливчик, который стал Assigned to, всегда знает, кто был тем доброжелателем, который сделал его держателем бага.
VERIFIER (ИМЯ ТОГО, КТО ДОЛЖЕН ПРОВЕРИТЬ РЕМОНТ)
Это ниспадающее меню с тем же списком имен сотрудников, что и в Assigned to.
Как мы помним, баг может быть занесен в СТБ любым сотрудником интернет-компании, который имеет счет в СТБ и соответствующую привилегию.
При занесении бага значение Verifier автоматически становится равным имени автора бага. После того как баг был зафиксирован
224
Тестирование Дот Ком. Часть 3
и отремонтированный код был доставлен на тест-машину, держателем бага должно стать лицо, указанное в Verifier.
Как правило, если баг заносится не тестировщиком, то "нетести-ровщик" сразу (при занесении) выбирает значение Verifier, чтобы умыть руки и позабыть об этом баге навсегда.
Кстати, каждый эккаунт в СТБ принадлежит к определенной группе. Как минимум таких групп 3:
• "Тестировщики" — сотрудники департамента качества;
• "Программисты" — сотрудники департамента программирования;
• "Прочие" — все остальные.
В зависимости от принадлежности эккаунта к определенной группе определяются его привилегии. Например, закрыть баг может только тот, кто принадлежит к группе "Тестировщики".
Кстати, можно настроить СТБ так, чтобы, когда "Прочие" заносят баг, значение Verifier не становилось автоматически равным Submitted By, a было пустым и "Прочие" обязаны (под страхом незанесения бага) выбрать значение Verifier.
Не будем больше о привилегиях, это отдельная песня, зависящая от компании и возможностей СТБ.
COMPONENT (КОМПОНЕНТ)
Это ниспадающее меню со списком, как правило, функциональных частей веб-сайта. Например, этот список вполне может быть таким вот коротким и скромным:
"Регистрация
Поиск
Корзина
Оплата
Другое"
При занесении бага в СТБ автор бага должен выбрать компонент, тестируя который он нашел заносимый баг. Что я могу еще сказать?..
FOUND ON (ГДЕ БЫЛ НАЙДЕН БАГ)
Это ниспадающее меню, которое включает
• имена тест-сайтов, обитающих на нашей тест-машине;
• скромное слово "ZJFЈ"' (машина для пользователей);
• Spec ("Спек");
• Other ("Другое").
Жизнь замечательных багов
225
Например, в нашем любезном сердцу проекте (www.testshop.rs) список Found on состоит из следующих друзей:
"www.old.testshop.rs,
www.main.testshop.rs,
LIVE,
Spec,
Other".
Понятно, что если значение Found on равно "LIVE", то это означает, что был пропущен баг, который через релиз добрался до машины для пользователей или, как говорят некоторые любители повыпендриваться, "Баг вышел на продакшн". Found on является обязательным для заполнения.
Немедленная польза от использования атрибута Found on заключается в том, что каждый, кто хочет воспроизвести занесенный баг, знает, гдеконкретно это можно сделать.
VERSION FOUND
(ВЕРСИЯ, В КОТОРОЙ БЫЛ НАЙДЕН БАГ)
Это ниспадающее меню с версиями веб-сайта, автор бага обязан выбрать значение, соответствующее номеру версии продукта, в которой был найден баг.
BUILD FOUND (БИЛД, В КОТОРОМ БЫЛ НАЙДЕН БАГ)
Это небольшое (примерно 10 символов) текстовое поле, куда автор бага обязан вбить номер билда, в котором был найден баг.
VERSION FIXED (ВЕРСИЯ С ПОЧИНЕННЫМ КОДОМ)
Это ниспадающее меню с версиями веб-сайта. После того как программист починил баг, он должен передать этот баг далее (релиз-инженеру), для того чтобы в итоге Verifier произвел регрессивное тестирование (у нас будет подробное объяснения процесса через 5 минут). Программист обязанвыбрать номер версии, соответствующий бранчу в CVS, куда он направил отремонтированный код.
Version Fixed может иметь, как одно из значений, "N/A " (Not applicable — "к данной ситуации неприменимо"), которое продюсер обязан выбрать, зафиксировав баг, найденный в спеке.
226
Тестирование Дот Ком. Часть 3
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) на ПО, исходя из принадлежности бага к определенной технической категории.
Жизнь замечательных багов
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
Например, пользователь не может добавить кредитную карту к своему эккаунтуи, следовательно, не может ничего купить на нашем веб-сайте.
Термин "блокирование" также связан с понятием "обходной путь" (workaround), а вернее, с отсутствием этого пути. Например, согласно тест-кейсу нужно создать эккаунт путем использования тест-тула, но тест-тул не работает (баг в тест-туле является абсолютно легитимным багом!). Если есть возможность найти обходной путь, который разблокировал бы в данной ситуации тестирование, то баг не является блокирующим и не подходит под С2. Примером обходного пути в данном случае является создание эккаунта вручную.
СЗ — УМЕРЕННЫЙ
Функциональные проблемы (functional bugs) — под эту категорию подходят все функциональные баги, не подходящие под С1 и С2. Как правило, это простое расхождение между фактическим и ожидаемым результатами, когда все шаги тест-кейса (все этапы флоу) исполнены.
СА — КОСМЕТИЧЕСКИЙ
Косметическая проблема — баги, связанные с содержанием вебсайта (content), правописанием (spelling) и интерфейсом пользователя (User Interface).
Значение серьезности бага обязательно должно быть выбрано из списка, иначе баг нельзя занести в СТБ.
PRIORITY (ПРИОРИТЕТ БАГА)
Форма: ниспадающее меню со значениями от Ш до П4 (Ш—4) включительно.
Содержание: приоритет бага — это показатель важности бага для бизнеса компании.
Кстати, многие товарищи путают приоритет и серьезность. Коренное различие между ними кроется в том, что серьезность отражает технический аспект бага, а приоритет — коммерческий.
Дата добавления: 2018-05-02; просмотров: 812; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!