описать дефект в рамках поля Summary – действительно одно из главных достоинств и профессиональных навыков специалиста по тестированию. Есть несколько способов обучения этому навыку. Приведем три самых действенных и простых.
Метод «Что? Где? Когда?»
Нет, это не связано с привлечением знатоков из одноименного интеллектуального клуба. Этот способ подразумевает описание, которое дает ответы на три следующих вопроса.
1. Что произошло и в чем суть неполадки?
2. Где был обнаружен дефект?
3. Когда и при каких обстоятельствах возник дефект?
Это довольно действенный способ, и я рекомендую взять его на заметку.
Метод выделения ключевой информации
Весьма действенный метод, особенно когда у тебя уже есть длинное описание дефекта.
1. Попробуй описать дефект со всеми необходимыми деталями.
2. Внимательно прочитай свое описание и выдели из него ключевую информацию, то есть самые важные моменты.
3. Попробуй сложить эти ключевые моменты вместе.
То, что получится в итоге, и будет составлять Summary.
Метод тождественности атрибутов
Составь описание дефекта по следующей схеме.
1. Шаги воспроизведения
2. Ожидаемый результат
3. Полученный результат
Если все описано правильно, то «Полученный результат» и будет являться Summary дефекта. Если нужно, можешь добавить пару важных деталей.
Но вернемся к прочим атрибутам дефекта.
Подробное описание (Description) – это поле служит для того, чтобы тестировщик мог добавить более подробное описание и дать больше деталей. Здесь указывается любая дополнительная информация, относящаяся к багу, которая может помочь в исправлении дефекта.
Следующие два атрибута – Шаги (Steps) и Ожидаемый результат (Expected Result) – берутся непосредственно из твоего тест-кейса[11], с помощью которого ты обнаружил дефект. Это и понятно. Разработчик должен сделать абсолютно то же самое, чтобы увидеть этот баг. О том, как проектировать тест-кейсы, я расскажу тебе чуть позже.
Фактический результат (Result) – это описание того, что ты увидел своими глазами, выполнив необходимые для проверки Шаги. Если он не отличается от Ожидаемого результата, мы можем быть уверены, что система функционирует как нужно. Любое отличие между Ожидаемым и Фактическим результатом будет означать только одно: перед тобой дефект.
Критичность (Severity) – это основное, чем баги отличаются друг от друга. Определяя Критичность, ты информируешь разработчика, что тобой был выловлен баг, бажик или бажище.
Приоритет (Priority) – это фактически скорость, с которой разработчики должны отреагировать на найденный дефект. Похоже на то, как скорая помощь реагирует на разных больных: на скорость реагирования влияют признаки, характеризующие
Тест-кейс – это детально описанный сценарий или инструкция, которая позволяет тестировщикам выполнить определенные шаги для проверки определенной функциональности или поведения программного продукта. Это основной инструмент в процессе тестирования программного обеспечения, включая компьютерные игры.
