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

должен настроить последнюю так, чтобы исключить воз-

можность удаления багов пользователями СТБ.

Таким образом, каждый баг, когда-либо найденный в продукте,

будет иметь одно из трех упомянутых значений статуса.

RESOLUTION (РЕЗОЛЮЦИЯ)

Это ниспадающее меню со значениями:

Not Assigned (не приписан)

Assigned (приписан)

Fix in Progress (баг ремонтируется)

Fixed (баг отремонтирован)

Build in Progress (билд на тест-машину в процессе)

Verify (проведи регрессивное тестирование)

Fix is Verified (ремонт был успешен)

Verification Failed (ремонт был неуспешен)

Can't Reproduce (не могу воспроизвести)

Duplicate (дубликат)

Not a bug (не баг)

3rd party bug (не наш баг)

No longer applicable (поезд ушел)

236

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

Резолюция — очень важный атрибут, напрямую связанный со

статусом.

Если статус — это своего рода "жив", "умер", "реинкарнировался", то резолюция — это "поступил в институт", "женился", "купил

машину", т.е. резолюция — это детализация статуса.

Not Assigned (не приписан)

Такая резолюция может быть после того, как баг занесен, но лицо,

занесшее баг в СТБ, не знает, кто может этот баг зафиксировать.

Assigned (приписан)

К новому багу приписан держатель (owner), т.е. лицо, ответст-

венное за совершение следующего действия в отношении бага в

соответствии с процессом.

Как мы помним, у каждого открытого бага всегда есть дер-

жатель.

В случае резолюции Not Assigned держателем бага является автор

бага, не передавший его дальше.

Итак, меняем статус на Assigned, когда передаем баг для ремонта,

и выбираем имя из ниспадающего меню Assigned to.

Fix in Progress (баг ремонтируется)

Это значение резолюции выбирается программистом, когда он

начинает ремонт бага. Держатель бага — программист.

Fixed (баг отремонтирован)

Это значение резолюции выбирается программистом после того,

как он

• отремонтировал баг и

• сохранил код в CVS.

Держатель бага — релиз-инженер.

Build in Progress (билд на тест-машину в процессе)

Это значение резолюции выбирается релиз-инженером (а иногда

и билд-скриптом) после запуска на тест-машину билда с отре-

монтированным кодом, т.е. Build in Progress приходит на смену

Fixed.

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

237

Здесь нужно заметить, что если даже баг найден на машине для

пользователей, патч-релиз происходит только после того, как ре-

монт протестирован на тест-машине.

Держатель бага — релиз-инженер.

Verify (проведи регрессивное тестирование)

Это значение резолюции выбирается релиз-инженером (а иногда

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

Держатель бага — лицо, чье имя указано в Verifier. Если у вери-

фаера нет возможности проверить ремонт, то он может просто

выбрать другое значение Verifier так, чтобы его коллега принял

груз ответственности.

Fix is Verified (ремонт был успешен)

Регрессивное тестирования бага состоит из двух частей, следую-

щих одна за другой в таком порядке:

Часть 1:

проверка того, что баг был действительно починен, т.е.

четко следуем инструкциям из "Описания и шагов..." для вос-

произведения бага. Если функциональность работает как сле-

дует, то баг действительно был починен.

Часть 2:

проверка того, что ремонт бага не наплодил других багов.

Код — это тонкая материя, состоящая из множества взаимо-

зависимых компонентов, и чем сложнее ПО, тем труднее пред-

угадать, как изменение кода в одном месте отразится на рабо-

те всех закоулков системы. Если программист не указывает в

комментариях, какая часть ПО может быть попутно затронута

ремонтом, я в зависимости от ситуации

• прохожу по приоритетному флоу функциональности,

код которой был отремонтирован, и/или

• делаю энд-ту-энд-тест.

Пример с энд-ту-энд-тестом

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

не мог изменить количество книг. Энд-ту-энд-тест, который бы я сделал:

а) добавить в корзину книгу,

б) изменить количество книг и

в) произвести оплату.

238

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