testirovanie_dot-com

Я имя кнопки!!!

Кнопка (button)

Нажатие на кнопку является заключительным аккордом при заполнении веб-форм. Нажимая на кнопку, мы отправляем веб-форму для обработки на сервер с приложением (application server).

Кстати,

в большинстве случаевналичие ошибок призаполнении формы (например, обязательное для заполнения текстовое поле "Имя " пустое) проверяется не на сервере с приложением, а на компьютере пользователя.

ЭтоделаетсяпутемкодаJavaScript, являющегося частьюHTML-стра- ницы с веб-формой, и в случае ошибки в заполнении формы

выдается сообщение об ошибке, веб-форма не посылается на сервер сприложением.

Если неизвестно название кнопки, то при написании тест-кейсов просто напишите "отправьте форму" ("submit the form " или просто

"submit").

ATTACHMENT(ПРИЛОЖЕНИЕ)

Нет лучшей вещи при обмене информацией, чем хорошо подобранная иллюстрация, особенно наглядная иллюстрация. Наш мозг гораздо быстрее воспринимает зрительную информацию, чем текстовую, и мы, зная этот научный факт, можем организовать эффективную презентацию проблемы. Презентация может делаться, например, путем приложения снимка экрана (скриншота), на котором видна проблема. Вот самый технически элементарный и повсеместно распространенный способ для собственноручного изготовления скриншота:

а. На клавиатуре нажимаем кнопку PrtScrn.

б. Открываем стандартную программу Виндоуз, Paint. в. Нажимаем Ctrl+v.

г. Сохраняем графический файл (с расширениемJpeg или .gift. д. Прилагаем его к багу.

Кстати, как Paint, так и другие графические редакторы позволяют обвести, например, красным цветом место на скриншоте, где видна проблема (например, группу радиокнопок, которые можно выбрать одновременно). В общем большое поле для творчества.

Естественно, что приложением может быть не только наглядная иллюстрация в виде графического файла, но и любые другие файлы, которые помогут программисту быстрее и точнее понять суть проблемы.

Иногда бывают ситуации, что трудно описать проблему на родном языке, не говоря уже об иностранном. Что делаем? Прилагаем файл с иллюстрацией проблемы в поле "Описание и шаги для воспроизведения проблемы" и скромно пишем "Смотри при-

ложение" (See attachment).

Кстати, фраза "Смотри приложение" должна быть в поле "Описание и шаги..." в любом случае — чтобы каждый, кто просматривает занесенный вами баг, наверняка открыл и приложение.

SUBMITTED BY (АВТОР БАГА)

СТБ автоматически присваивает значение этому атрибуту. Как нетрудно догадаться, значение "Submitted by " — это нередактируемый текст с именем товарища, занесшего баг в СТБ (товарищ далее именуется автором бага). Как правило, автором бага является тестировщик.

DATE SUBMITTED (ДАТА И ВРЕМЯ ПОЯВЛЕНИЯ БАГА)

Как и в случае с Submitted by, СТБ автоматически присваивает значение этому атрибуту. Как нетрудно догадаться, значение "Date submitted" — это нередактируемый текст с датой и временем, когда баг был занесен в СТБ своим отцом — автором.

ASSIGNED TO (ДЕРЖАТЕЛЬ БАГА)

Каждый открытый баг в каждый конкретный момент имеет своего конкретного держателя (Owner). Держатель бага — это участник процесса разработки ПО, на котором лежит ответственность сделать следующий шаг на пути к закрытию бага. Варианты следующего шага определяются процессом.

Когда баг заносится в СТБ, то автор бага обязательно должен выбрать имя из списка ниспадающего меню "Assigned to " (СТБ выдаст ошибку, если имя не выбрано). Список "Assigned to " состоит из имен всех пользователей, кто имеет эккаунты в СТБ. Например, мое имя пользователя в СТБ может выглядеть какг savin.

Кстати, счета в СТБ открывает администратор СТБ, который, как правило, является вашим коллегой-тестировщиком, корпящим в соседнем отсеке по другую сторону серой стенки, украшенной постером с силовой подачей Марии Шараповой.

Если автор бага

•не знает, кто из программистов должен ремонтировать этот баг, или

•вообще не знает, что ему делать с этим багом,

то он просто выбирает из "Assigned to " самое родное и близкое, что он может там найти, — свое имя.

В каждой интернет-компании на интранете должна быть страничка "Кто за что ответствен" (Who does What). На этой стра-

ничке должны быть перечислены:

•компоненты веб-сайта (теже, чтои в атрибуте "Компонент", о нем чуть позже);

•программисты, которые отвечают за эти компоненты;

•продюсеры, которые отвечают за эти компоненты.

Пример

Нужно, чтобы эта страничка постоянно поддерживалась, например, менеджерами программистов и продюсеров, чтобы отражать текущее состояние компонентов и ответственных лиц:

если в компании 3 человека, сидящие в одном закутке 4x3 метра, то каждый примерно знает, что делают двое других. Если же компания растет и развивается, работники приходят, переводятся с участка на участок, уходят, функциональности появляются, модифицируются, исчезают... в общем перемены бьют ключом, то наличие централизованного источника информации о программистах и продюсерах — собственниках функциональностей является наиудобнейшей и наиполезнейшей вещью (хотя бы для того, чтобы быстро и правильно выбрать имя из

"Assigned to ").

Кстати,авторомбагаможетбытьнетолькотестировщик. Любойпользователь СТБ, имеющий право (privilege) на занесение багов в СТБ, может быть автором бага. Технически права даруются (как, впрочем, и отнимаются) администратором СТБ.

Кстати, выражение "занести баг" по-аглицки звучит как "file a bug" или

"reporta bug".

Кстати, программисты часто заносятбаги против своегоже кода. Это не мазохизм, а холодный расчет, так как

•соднойстороны,сохранять багивСТБпростоудобно,а

•с другой —программистдолжен тратитьвремянаремонтбага, и баг,занесенный в СТБ, оправдываеттакую трату вглазах начальства, коллег и семьи.

Кстати, программисты любят играть багом в пинг-понг, меняя значение Assigned to на имена друг друга, говоря таким образом: "Это, дорогой, не мой, а твой баг", "Нет, я думаю, что это как раз твой баг", "Я не уверен,что ты прав. Этотбагвсе-таки твой"и т.д. Результатом таких игр является задержка в фиксировании бага.

Небольшой нюанс. Люди приходят в интернет-компанию и уходят из нее. Когда они приходят, администратор СТБ создает им счета, а когда они уходят, то эти счета НИКОГДА не удаляются: администратор СТБ просто маркирует счет бывшего коллеги как недействительный, т.е. им нельзя больше пользоваться. При этом имя пользователя СТБ в списке пользователей СТБ остается. Принцип неудалениянужен длясохраненияданных, связанныхсзанесенными багами.

ASSIGNEDBY(ИМЯПЕРЕДАВШЕГОБАГ)

Значение этого атрибута (как и Submitted by) является нередактируемым текстом. СТБ автоматически присваивает атрибуту Assigned by имя пользователя СТБ, который выбрал значение Assigned to. Таким образом, счастливчик, который стал Assigned to, всегда знает, кто был тем доброжелателем, который сделал его держателем бага.

VERIFIER(ИМЯТОГО,КТОДОЛЖЕНПРОВЕРИТЬРЕМОНТ)

Это ниспадающее меню с тем же списком имен сотрудников, что и в Assigned to.

Как мы помним, баг может быть занесен в СТБ любым сотрудником интернет-компании, который имеет счет в СТБ и соответствующую привилегию.

При занесении бага значение Verifier автоматически становится равным имени автора бага. После того как баг был зафиксирован

и отремонтированный код был доставлен на тест-машину, держателем бага должно стать лицо, указанное в Verifier.

Как правило, если баг заносится не тестировщиком, то "нетестировщик" сразу (при занесении) выбирает значение Verifier, чтобы умыть руки и позабыть об этом баге навсегда.

Кстати, каждый эккаунт в СТБ принадлежит к определенной группе. Как минимум таких групп 3:

•"Тестировщики"—сотрудникидепартаментакачества;

•"Программисты"—сотрудникидепартаментапрограммирования;

•"Прочие"—всеостальные.

Взависимости от принадлежности эккаунта к определенной группе определяются его привилегии. Например, закрыть баг может только тот, кто принадлежит к группе "Тестировщики".

Кстати, можно настроить СТБ так, чтобы, когда "Прочие" заносят баг, значение Verifier не становилось автоматически равным Submitted By, a было пустым и "Прочие" обязаны (под страхом незанесения бага) выбрать значение Verifier.

Не будем больше о привилегиях, это отдельная песня, зависящая от компании и возможностей СТБ.

COMPONENT(КОМПОНЕНТ)

Это ниспадающее меню со списком, как правило, функциональных частей веб-сайта. Например, этот список вполне может быть таким вот коротким и скромным:

"Регистрация Поиск Корзина Оплата Другое"

При занесении бага в СТБ автор бага должен выбрать компонент, тестируя который он нашелзаносимый баг.Чтоямогуещесказать?..

FOUNDON(ГДЕБЫЛНАЙДЕНБАГ)

Это ниспадающее меню, которое включает

•имена тест-сайтов, обитающих на нашей тест-машине;

•скромное слово "ZJFЈ"' (машина для пользователей);

•Spec ("Спек");

•Other ("Другое").

Например, в нашем любезном сердцу проекте (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 — "к данной ситуации неприменимо"), которое продюсер обязан выбрать, зафиксировав баг, найденный в спеке.

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) на ПО, исходя из принадлежности бага к

определенной технической категории.

Например, пользователь не может добавить кредитную карту к своему эккаунтуи, следовательно, не может ничего купить на нашем веб-сайте.

Термин "блокирование" также связан с понятием "обходной путь" (workaround), а вернее, с отсутствием этого пути. Например, согласно тесткейсу нужно создать эккаунт путем использования тест-тула, но тест-тул не работает (баг в тест-туле является абсолютно легитимным багом!). Если есть возможность найти обходной путь, который разблокировал бы в данной ситуации тестирование, то баг не является блокирующим и не подходит под С2. Примером обходного пути в данном случае является создание эккаунта вручную.

СЗ — УМЕРЕННЫЙ

Функциональные проблемы (functional bugs) — под эту категорию подходят все функциональные баги, не подходящие под С1 и С2. Как правило, это простое расхождение между фактическим и ожидаемым результатами, когда все шаги тест-кейса (все этапы флоу) исполнены.

СА — КОСМЕТИЧЕСКИЙ

Косметическая проблема — баги, связанные с содержанием вебсайта (content), правописанием (spelling) и интерфейсом пользователя (User Interface).

Значение серьезности бага обязательно должно быть выбрано из списка, иначе баг нельзя занести в СТБ.

PRIORITY (ПРИОРИТЕТ БАГА)

Форма: ниспадающее меню со значениями от Ш до П4 (Ш—4) включительно.

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

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

Кстати, многие товарищи путают приоритет и серьезность. Коренное различие между ними кроется в том, что серьезность

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

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

Так, если сайт рушится (crash), то это С1, и мы не можем, например, по политическим соображениям изменить серьезность такого бага, например, на С2, так как ситуация (с системным сбоем) четко соответствует дефиниции С1. Если же тестировщик назначил приоритет как П1, то программист вполне