tестирование dot com
Шрифт:
сле этого садимся за стол и записываем вещи, которые обманули
ожидания (т.е. баги), на пронумерованные страницы новой тетради
в клеточку. Один баг на одну страницу.
Например
на странице под номером 1 пишем: "Неудобно пользоваться навигаци-
онной системой";
на странице под номером 2 пишем: "Задержка в ускорении после на-
жатия на педаль акселератора";
"Слишком маленький багажник".
Наша ни в чем не повинная тетрадь на самом деле является не
только выброшенными на ветер деньгами, но и простейшей вер-
сией того, что называется системой трэкинга багов (СТБ).
Вспомним о тестировании. Опять же на примитивном уровне СТБ
может представлять собой простой текстовый файл с записями о
багах, который лежит на интранете и доступен участникам цикла
разработки ПО.
Итак, концептуально СТБ — это инфраструктура, позволяющая
• создавать,
• хранить,
• просматривать и
• модифицировать
информацию о багах.
Существует множество профессиональных СТБ — от бесплатной
Багзиллы (Bugzilla) до многотысячедолларового тест-директора (Test
Director by Segue), и естественно, что интернет-компании исполь-
зуют для трэкинга багов не тетрадки или текстовые файлы, а именно
специальное ПО, непосредственно созданное для трэкинга багов.
О таком ПО и процессе трэкинга багов мы и поговорим сегодня.
Каждый баг, занесенный в СТБ, представляет собой вирту-
альную учетную карточку
208
Тестирование Дот Ком. Часть 3
Каждая такая карточка существует не сама по себе, а как часть
процесса трэкинга багов (далее — Процесс).
С каждым багом, занесенным в СТБ, начинается новый Процесс.
Вопрос: Как определить, на какой стадии Процесса находится
каждая конкретная карточка?
Ответ: Ничего нет проще — нужно просто посмотреть на ее ат-
рибуты.
Пример
Одним из атрибутов является статус бага. Статус может принимать
одно из трех значений:
• Open (открыт),
• Closed (закрыт) либо
• Re-open (повторно открыт).
Пример Процесса
После того как баг заносится в СТБ, его статус автоматически стано-
вится "Open"; после того как баг зафиксирован и регрессивное тести-
рование подтвердило успех починки, мы меняем статус на "Closed";
если же тот же баг, после того как мы его закрыли, был найден снова,
то мы меняем "Closed" на "Re-Open".
Важно понять, что Процесс как формальный свод правил перви-
чен и такой зверь, как СТБ, приобретается именно как инстру-
мент для материализации Процесса.
Другими словами, после инсталляции ответственный товарищ
настраивает СТБ в соответствии с процессом, выбранным компа-
нией, а не наоборот.
В примере со статусом мы взглянули на процесс с высоты птичь-
его полета. Опустимся же на землю и увидим все подробности.
Допустим, мы нашли баг. Сам факт нахождения бага, даже если
это критический дефект, не имеет никакого значения и веса, пока
вы не сообщили об этом баге. Два вопроса:
Кому сообщить?
Как сообщить?
Кому? Программисту, если это баг кода, либо продюсеру, если
это баг спека.
Как? Здесь есть много путей: можно позвонить, послать е-мейл,
сказать пару ласковых при личной встрече и т.д.
Жизнь замечательных багов
209
Стандартный путь, принятый в софтверных компаниях, — это занести
баг в СТБ.
Таким образом, одной из основных функций СТБ является обес-
печение коммуникации между участниками Процесса.
Как фактически происходит занесение бага в СТБ? Например, так: вы
• открываете веб-браузер;
• печатаете в нем URL вашей СТБ в локальной сети и нажимаете
Enter;
• после того как загрузилась страница СТБ, вводите имя
пользователя и пароль;
• нажимаете на кнопку "New bug" (Новый баг);
• на веб-форме "Новый баг" заполняете поля и выбираете
значения;
• нажимаете на кнопку "Submit new bug" (Занести новый баг).
Все очень просто.
Кстати, отныне баг в зависимости от контекста будет иметь одно из
следующих значений или оба значения:
• баг как отклонение фактического результата от ожидаемого ре-
зультата и/или
• баг как созданная в СТБ виртуальная учетная карточка, являю-
щаяся, по чьему-либо субъективному мнению, презентацией не-
кой проблемы.
В чем разница, спросите вы. Отвечаю: проблема, занесенная в СТБ,