tестирование dot com

вым не является.

Например

мы исполняем тест-кейс по проверке одного из флоу функционально-

сти "Оплата" и видим, что отсутствует поле для ввода номера CW2. Мы

заносим баг и получаем его обратно с резолюцией No Longer Applicable

и комментарием программиста, что согласно багу #7723 с типом "Fea-

ture Request" мы больше не должны спрашивать CW2 у пользователя.

Таким образом, до занесения продюсером бага #7723 ситуация с от-

сутствующим CW2 была бы багом, а теперь это не баг.

Баги, возвращенные с резолюцией No longer applicable, как пра-

вило, возникают из-за отсутствия информации.

В моей практике, если фактический результат после исполнения

тест-кейса расходится с ожидаемым результатом по этому тест-кей-

су, я пытаюсь воспроизвести баг заново, и если он воспроизводится,

то я сразу же заношу его в СТБ. Если же я вижу проблему, которая

не связана с моим ожидаемым результатом и/или функциональ-

ностью, о которой я имею полную информацию, то обычно контак-

тирую с коллегами-тестировщиками, которые владеют вопросом

о функциональности, в которой, как мне кажется, есть баг.

Резолюция No longer applicable позволяет закрыть баг, если он на

самом деле больше не баг.

Процесс трэкинга багов

Теперь, после того как мы поговорили об атрибутах СТБ, посмот-

рим на блок-схему. На ней мы воочию видим основу процесса

трэкинга багов. Эта основа сама по себе является стандартной

версией процесса, и интернет-компании используют ее в таком

либо измененном виде.

246

Тестирование Дот Ком. Часть 3

Процесс трэкинга багов

Жизнь замечательных багов

247

Кстати, для упрощения допустим, что баг заносится тестиров-

щиком (хотя мы знаем, что баг может заноситься кем угодно)

и против кода программиста (хотя мы знаем, что существуют

и баги спека, которые заносятся против продюсера).

Давайте сделаем так:

• сначала рассмотрим процесс концептуально, затем

• привяжем к каждой его стадии наши атрибуты (детальное

рассмотрение процесса), затем

• приведем конкретный пример.

Концептуальное рассмотрение процесса трэкинга багов

Задача 1: После того как мы нашли проблему в ПО, заносим новый

баг.

Задача 2: Программист получает баг, старается понять, в чем про-

блема, и если это действительно баг, то

Задача 3: Программист начинает ремонт.

Задача 4: После того как ремонт закончен, программист

должен сделать checkin кода в CVS.

Задача 5: Релиз-инженер запускает новый билд, чтобы от-

ремонтированный код пришел из CVS на тест-ма-

шину.

Задача 6: Тестировщик проводит регрессивное тестирова-

ние, и если починка НЕ удалась, то

Задача 7: Баг возвращается программисту на но-

вый ремонт.

Если же починка удалась, то

Задача 8: Баг закрывается. Goodbye my love, Goodbye.

Идем обратно к развилке после задачи 2. Допустим, программист

не считает, что зарапортованная ситуация является багом. Тогда он:

Задача 9: Возвращает баг.

Задача 10: Тестировщик старается понять свою ошибку, и

если ошибка имела место и баг соответственно

места не имел, то

Задача 8: Баг закрывается.

Если же тестировщик считает, что это все-таки баг, то

баг отправляется обратно программисту.

Задача 2: Программист снова пытается понять, баг ли это. И т.д.

248

Тестирование Дот Ком. Часть 3

Детальное рассмотрение процесса

Давайте вольем в рассмотренную форму содержимое, состоящее

из атрибутов и их значений, как мы хотим это нашей компании

www.testshop.rs.

Задача 1:

Атрибут

Комментарий по заполнению либо

конкретное(ые) значение(я) атрибута

Summary

Краткое описание

Description and Steps

Описание и шаги...

to Reproduce

Attachment

Используем это поле, если нужна дополнительная

иллюстрация

Assigned to

Имя программиста

Component

Название компонента

Found on

Где был найден баг

Version Found

Номер версии

Build Found

Номер билда

Severity

Значение серьезности

Priority

Значение приоритета

Notify list

По минимуму — имя продюсера

Type

"Bug"

Resolution

"Assigned"

Задача 2:

Программист признает, что это баг:

Задача 3:

Resolution

"Fix in Progress"

Задача 4:

Resolution

"Fixed"

Version Fixed

Номер версии

Build Fixed

Номер билда

Assigned to

Имя релиз-инженера

Задача 5:

Resolution

"Build in Progress"

Жизнь замечательных багов

249

и после того, как новый билд появился на тест-машине: