tестирование dot com
Шрифт:
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
Таким тестом мы проверяем, что флоу, в которое включен отремонти-
рованный компонент, все еще работает.
Изменить резолюцию на Fix is Verified можно непосредственно
после успешного завершения части 1.
При значении Fix is Verified можно закрыть баг. После закрытия
бага у него нет держателя, так как его некуда больше передавать.
После того как резолюция стала Fix is Verified и до закрытия бага
держателем бага является товарищ, который выбрал эту резолюцию.