QA Engineer

Их также можно использовать на низком уровне. В этом случае анализ входных значений и применение техник тест-дизайна можно выполнять прямо во время тестирования.

Пример

Преимущества чек-листа очевидны:

— Простота и широта применения.

— Написание проверок низкого уровня в таком виде позволяет не тратить время на документацию и заниматься непосредственно тестированием системы.

Недостатки чек-листа заключаются в следующем:

— Отсутствие конкретики на низком уровне тестирования требует от QA инженера навыков, соразмерных сложности задачи. И даже в таком случае есть заметный риск пропустить некоторые проверки.

— В случае любых вопросов к тому, как именно проводится тестирование функционала, нет четкого понимания, как и с какими данными его проводили или будут проводить.

5.1.2. Test Case

Test Case (тест-кейс) — это документ, направленный на проверку конкретного функционала или требования к системе с высоким уровнем подробностей.

Применение техник тест-дизайна порождает несколько наборов тестовых данных, которые можно описать одним или группой тест-кейсов. Каждый из них имеет определенные атрибуты:

— Название — оно должно быть коротким, но отражающим цель описанных в тест-кейсе проверок.

— Предварительные условия (могут быть пустыми) — описывают состояние всего приложения или его частей, а также необходимость выполнить предварительные шаги перед началом тестирования.

— Шаги — набор последовательных действий для получения ожидаемого отклика системы.

— Ожидаемый результат — состояние системы, которое должно получиться после выполнения шагов, обычно напрямую связано с конкретным требованием к приложению.

— Фактический результат (заполняется после прохождения тест-кейса) — фактическое состояние системы после выполнения шагов.

Пример

Фактический результат обычно отражается не полноценным описанием состояния системы, а статусами: «Успешно», «Заблокировано», «Неуспешно». Это связано с тем, что более подробное описание в случае неуспешного прохождения отражается в Bug Report.

Тест-кейс является достаточно сложным и одновременно важным документом для того, чтобы иметь критерии, по которым можно определить его качество. Глобально тест-кейсы неразрывно связаны с требованиями к системе и потому имеют схожие критерии качества.

Понимание уровня качества тест-кейсов на проекте на самом деле может сказать о многом. Во-первых, факт того, что на проекте отслеживают уровень качества, говорит о желании стремиться к эффективным проверкам или хотя бы стабильности в этом вопросе. Во-вторых, это означает, что кому-то на проекте важно иметь прозрачные и контролируемые проверки. В-третьих, это говорит о выстроенных вокруг этой потребности процессах и ответственных за это сотрудников компании. Однако понять то, насколько заботятся об уровне качества и какие процессы для этого выстроены, может быть сложно без погружения в контекст проекта.

Критерии качества тест-кейсов:

— Следование цели — документ должен указывать на определенную цель проверок, а все его атрибуты должны вести к выполнению этой цели.

— Точность — формулировки документа точно и не двусмысленно указывают на необходимость выполняемых действий, ожидаемый результат или объекты, использующиеся в документе.

— Единообразие — в тест-кейсе должны быть одинаковые формулировки и единый формат. Также стоит учитывать другие рекомендации, установленные на проекте.

— Непротиворечивость — все атрибуты документа не противоречат сами себе, то есть полностью согласованы между собой.

— Модифицируемость — формулировка и структура документа написаны таким образом, чтобы в будущем из-за обычных изменений не приходилось исправлять значительную часть тест-кейса.

— Отсутствие избыточности — отсутствие лишних действий или проверок, не относящихся достижению цели, а также длинных формулировок, которые можно сократить без потери смысла. Это свойство также касается согласованности проверок с другими тест-кейсами: нет необходимости выполнять одни и те же проверки в нескольких документах.

— Полнота — документ должен содержать абсолютно всю информацию, чтобы достичь цели тестирования, ради которой он создан, и сравнить ожидаемый результат с фактическим.

— Прослеживаемость — свойство тест-кейса, которое позволяет понять, какое именно требование к системе в нем проверяют. Лучше всего этого можно достигнуть с помощью матрицы трассировки требований, о которой будет сказано позже.

Немного практических советов

Обратите внимание на формулировки в вашем тест-кейсе и то, в каком времени они указаны. Описывая предварительные условия вашего документа, лучше придерживаться формулировки, отвечающей на вопросы «Что сделано?» или «Что должно быть сделано?». Шаги проверок стоит описывать, отвечая на вопрос «Что сделать сейчас?». Ожидаемый результат лучше описывать как завершенное сбывшееся действие, отвечая на вопрос «Что сделано/получено/запущено?»