1. Теория тестирования
1.7. Тестовые артефакты
Тестовые артефакты
В соответствии с процессами или методологиями разработки ПО, во время проведения тестирования создается и используется определенное количество тестовых артефактов (документы, модели и т.д.). Наиболее распространенными тестовыми артефактами являются:
- План тестирования (Test Plan) - это документ описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
- Тест-кейс (Test Case) - это последовательность действий, по которой можно проверить соответствует ли тестируемая функция установленным требованиям.
Под тест-кейсом понимается структура вида:
Action > Expected Result > Test Result
Пример:
| Action | Expected Result | Test Result (passed/failed/blocked) |
|---|---|---|
| Open page "login" | Login page is opened | Passed |
Виды Тестовых Случаев
Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:
Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.
Каждый тест кейс должен иметь 3 части:
| PreConditions | Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния. |
|---|---|
| Test Case Description | Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям |
| PostConditions | Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state) |
Примечание: Post Conditions не является обязательной частью. Это скорее всего - правило хорошего тона: "намусорил - убери за собой". Это особенно актуально при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов.
- Тест-сьют (Test Suite) - это комбинация тест-кейсов для проверки определенной части программного обеспечения, объединенная общей функциональностью или целями, преследуемыми запуском данного набора.
- Чек-лист (Сhecklist) - это высокоуровневый список проверок, методика заполнения которого основывается на опыте. Пример:
- Дефекты / Баг Репорты (Bug Reports / Defects) - это документы, описывающие ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Шаблон баг-репорта:
Градация Серьезности дефекта (Severity)
S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее
состояние, в результате которого дальнейшая работа с тестируемой
системой или ее ключевыми функциями становится невозможна. Решение
проблемы необходимо для дальнейшего функционирования системы.
S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая
бизнес логика, дыра в системе безопасности, проблема, приведшая к
временному падению сервера или приводящая в нерабочее состояние
некоторую часть системы, без возможности решения проблемы, используя
другие входные точки. Решение проблемы необходимо для дальнейшей работы с
ключевыми функциями тестируемой системой.
S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики
работает некорректно. Ошибка не критична или есть возможность для работы
с тестируемой функцией, используя другие входные точки.
S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику
тестируемой части приложения, очевидная проблема пользовательского
интерфейса.
S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики
приложения, плохо воспроизводимая проблема, малозаметная посредствам
пользовательского интерфейса, проблема сторонних библиотек или сервисов,
проблема, не оказывающая никакого влияния на общее качество продукта.
Градация Приоритета дефекта (Priority)
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.
Порядок исправления ошибок по их приоритетам:
High -> Medium -> Low
Источники: https://protesting.ru/testing/testdeliverables.html, ISTQB - силлабус