tестирование dot com
Шрифт:
фактического от ожидаемого).
Логичным будет вопрос: почему мы употребили выражение
"срочное изменение"?
Вот ответ: если нужна новая функциональность, то продюсер
пишет спек, программист его кодирует и т.д. в соответствии с про-
цессом разработки ПО. Каждая стадия процесса имеет свои вре-
менные рамки, которые привязаны к расписанию релизов (release
schedule). А что, если
ность в новой фича и ее нужно срочно выпустить?
Пример
Допустим, мы выпускаем один основной релиз в месяц. Сегодня 10
ноября, и последний основной релиз (7.0) состоялся 31 октября.
Если сегодня (Ю ноября) появилась новая идея (например, о добавле-
нии кепча на страницу регистрации), то если мы включим ее в наш
процесс разработки как любую очередную идею, то наша многостра-
дальная кепча появится на машине для пользователей не 1 декабря в
релизе 8.0 (так как все спеки релиза 8.0 уже заморожены), а 1 января
в релизе 9.0. Таким образом, придется ждать больше полутора меся-
цев. Что делать, если у нас нет полутора месяцев, а есть полтора часа ?
Нужно занести баг "Feature request" с приоритетом П1. Если же фича
может подождать до 8.0, то опять же заносим баг с типом "Feature re-
quest", но уже с приоритетом ПЗ.
Вот такие дела...
STATUS (СТАТУС)
Это ниспадающее меню со значениями:
• Open (Открыт),
• Closed (Закрыт),
• Re-Open (Повторно открыт).
Значение Open присваивается багу автоматически при занесении бага.
Закрыть баг можно только при соответствующей резолюции (об этом
через минуту).
Значение Re-Open выбирается тестировщиком, когда он возрож-
дает к жизни закрытый баг.
Почему возникают ситуации, когда баги приходится открывать
заново?
Жизнь замечательных багов
235
Например
• программист сделал изменение в коде и поломал отремонтиро-
ванный
чае говорят о том, что баг был reintroduced ("заново внесен на рас-
смотрение" — так себе перевод, но ничего лучше я не нашел);
• баг был найден на машине для пользователей. Программист сде-
лал checkin отремонтированного кода в бранч-версии машины для
пользователей и позабыл сделать checkin в ствол. Следовательно,
в следующем релизе баг появляется снова.
В связи со статусом запомним две вещи:
• ВСЕ найденные баги должны заноситься в СТБ. Исклю-
чений быть не может. Ваша работа как тестировщика —
искать баги. Единственный и неповторимый результат вашей
работы — баг, занесенный в СТБ. Умные программисты ни-
когда на вас не обидятся, так как качество их работы измеря-
ется не количеством багов, ими допущенных, а скоростью,
с которой они эти баги чинят (почти по Глебу Жеглову);
• занесенные в СТБ баги НИКОГДА не удаляются из СТБ.
Чтобы ни случилось, пока живет компания, ее СТБ вклю-
чает ВСЕ баги, найденные в продукте. Администратор СТБ
должен настроить последнюю так, чтобы исключить воз-
можность удаления багов пользователями СТБ.
Таким образом, каждый баг, когда-либо найденный в продукте,
будет иметь одно из трех упомянутых значений статуса.
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 (не наш баг)