Серьезность
Степень влияния дефекта на выполнение тестов и/или бизнес-функции
Приоритет
Классификация дефектов, указывающая на срочность или важность устранения дефекта
Дата обнаружения
Дата, когда дефект был обнаружен
Краткое описание
Высокоуровневое описание дефекта
Шаги по воспроизведению
Подробные шаги для воспроизведения дефекта (например, Шаг 1: войти в систему, используя идентификатор клиента: xx123; Шаг 2: нажать кнопку Transfer)
Ожидаемый результат
Ожидаемые результаты теста (например, отображение страницы Transfer)
Фактические результаты
Фактические результаты теста (например, отображается страница ошибки Error page)
Ссылка
Ссылка на тест-кейс или требование
Подтверждение
Подтверждения наличия дефекта (например, скриншоты, вложения, результаты SQL-запросов)
ID дефекта
Идентификационный номер для уникальной идентификации каждого дефекта
Вид дефекта
Категоризирует дефекты как статические, функциональные или нефункциональные
Среда
Среда, в которой обнаружен дефект
Уровень
Описание
Пример
1
Критический
Компонент системы не работает или непригоден для использования. Альтернативы ему не существует. Тестирование не может быть продолжено
2
Высокий
Компонент системы не работает или непригоден для использования, влияние критическое, но имеется альтернатива. Тестирование может быть продолжено в ограниченном объеме
3
Средний
Функциональность компонента системы ограничена. Влияние дефекта не критическое, но определенным образом затрагивает работу системы. Может быть продолжено тестирование не связанных с компонентом областей
4
Низкий
Влияние на работу системы отсутствует. Тестирование может быть продолжено
Понятие «риск продукта» означает, что созданный программный продукт или пакет не соответствует цели, для которой он разрабатывался
Понятие «риск продукта» означает, что созданный программный продукт или пакет не соответствует цели, для которой он разрабатывался
Тестирование на основе опыта обычно служит дополнением к более структурированным методам тестирования. Оно часто применяется в случаях, когда базис тестирования, который можно было бы использовать для создания тест-кейсов, отсутствует или недостаточен.
Тестирование методами «черного» и «белого ящика» можно сочетать с методами на основе опыта, что позволяет использовать практические знания разработчиков, тестировщиков и пользователей, чтобы определить, что именно нужно тестировать.
Методы тестирования на основе опыта используют опыт разработчиков, тестировщиков и пользователей для разработки, реализации и выполнения тестов.
Эти методы проверяют структуру тестируемого объекта. Условия тестирования, тест-кейсы и тестовые данные формируются на основе базиса тестирования, который может включать код, архитектуру программного обеспечения, детали проекта или любой другой источник информации о структуре ПО.
Тестирование по методу «белого ящика» (также называемое структурным или тестированием на основе структуры) основано на анализе архитектуры, деталей проекта, внутренней структуры или кода тестируемого объекта.