Текст книги "tестирование dot com"

Автор книги: Роман Савин

сообщить о нарушении

Текущая страница: 12 (всего у книги 17 страниц)

отделов без проблем воспроизводили баги и нахваливали ваши

описания.

Вот небольшой список наиболее часто встречающихся элемен-

тов веб-страницы, который позволит вам более четко описывать

и шаги для воспроизведения багов, и шаги тест-кейсов.

Я текст. Вещь незаменимая

Текст (text)

Не знаю, какое описание дать здесь. Текст есть текст.

Кстати:

1. Текст может быть неверного содержания* (противоречащий

спеку): например, неверное сообщение об ошибке.

2. Нужного текста может не быть вовсе*.

3. Может быть неправильным шрифт (font), цвет (color), размер

(size) текста.

Естественно, что проблемы неверного содержания элемента или полного его

отсутствия могут быть не только у текста, но и у всех остальных элементов.

Я линк. Просто линк

Линк (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ак:

Verify Your Registration

More info

*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

ADDRESS 1

ADDRESS2

CITY

STAT

Country ZIP CODE

ID

E

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

RECORDJ

ADDRESS 1

ADDRESS2

CITY

STAT

Country ZIP CODE

D

E

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

Paris

France 75018

de Clichy

Кстати, хорошей идеей для ввода при тестировании является описа-

тельный ввод, например, в текст-бокс Адрес 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 ap-

plicable – «к данной ситуации неприменимо»), которое продюсер

обязан выбрать, зафиксировав баг, найденный в спеке.

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)

включительно.

Содержание: приоритет бага – это показатель важности бага

для бизнеса компании.

Кстати, многие товарищи путают приоритет и серьезность. Ко-

ренное различие между ними кроется в том, что серьезность

отражает технический аспект бага, а приоритет – коммер-

ческий.

Серьезность – это категория абсолютная. Приоритет – это

категория относительная.

Так, если сайт рушится (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 – все понятно.

ПЗ – каждая стадия цикла разработки ПО имеет свои запланирован-

ные временные рамки. Таким образом, если релиз должен состояться