Раздел: Тестирование > Тестовые Артефакты > Тестовый случай (Test Case)
Тестовый случай (Test Case)
Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Под тест кейсом понимается структура вида:
Action > Expected Result > Test Result
Пример:
| Action | Expected Result | Test Result (passed/failed/blocked) |
|---|---|---|
| Open page "login" | Login page is opened | Passed |
Виды Тестовых Случаев
Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:
- Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
- Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.
Структура Тестовых Случаев (Test Case Structure)
На просторах интернета вы сможете найти очень много информации о структуре тест кейсов, уровне их детализации и количестве проверок в них, я собираюсь рассказать о подходе используемом мной, и который я хочу предложить использовать вам.
Каждый тест кейс должен иметь 3 части:
| PreConditions | Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния. |
|---|---|
| Test Case Description | Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям |
| PostConditions | Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state) |
Примечание: Post Conditions не является обязательной частью. Это скорее всего - правило хорошего тона: "намусорил - убери за собой". Это особенно актуально при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов.
Пример тест кейса:do A1, verify B1
do A2, verify B2
do A3, verify B3
В приведенном примере конечная проверка - В3. Это значит, что именно она является ключевой. Значит, A1 и А2 - это действия приводящие систему в тестопригодное состояние. А В1 и В2 - условия того, что система находится в состоянии пригодном для тестирования. Таким образом имеем:
| Action | Expected Result | Test Result (passed/failed/blocked) |
|---|---|---|
| PreConditions | ||
| do A1 | verify B1 | |
| do A2 | verify B2 | |
| Test Case Description | ||
| do A3 | verify B3 | |
| PostConditions | ||
PostConditions в данном примере не были описаны, но по логике вещей надо выполнить шаги, которые бы вернули систему в первоначальное состояние. (например, удалили созданную запись, или отменили бы изменения сделанные в документе)
Теперь ответим на вопрос: "Почему данное разбиение удобно использовать?"
Ответ: конечная проверка одна, т.е. в случае если тест провален (test failed) будет сразу ясно из-за чего. Т.к. если провальными окажутся проверки В1 и/или В2, то тест кейс будет заблокирован (test blocked), из-за того, что функцию не возможно привести в тестопригодное состояние (состояние пригодное для проведения тестирования), но это не значит, что тестируемая функция не работает.
| Action | Expected Result | Test Result (passed/failed/blocked) |
|---|---|---|
| PreConditions | ||
| do A1 | verify B1 | passed |
| do A2 | verify B2 | failed |
| Test Case Description: | ||
| do A3 | verify B3 | blocked |
| PostConditions | ||
Детализация описания тест кейсов (Test Case Specification)
Бытует много разных мнений об уровне детализации при написании тест кейсов, а также количестве проверок в одном тест кейсе. Все они по своему правильные. Мое мнение, что уровень детализации тест кейсов должен быть таков, чтобы обеспечивать разумное соотношение времени прохождения к тестовому покрытию. Т.е. до тех пор пока покрытие тестами определенного функционала не меняется, можно уменьшать детализацию тест кейсов.
Пример тест кейса 1:
Проверка отображения страницы |
||
| Действие | Ожидаемый результат | Результат теста |
|---|---|---|
| Открыть страницу "Вход в систему" | - Окно "Вход в систему" открыто - Название окна - Вход в систему - Логотип компании отображается в правом верхнем углу - На форме 2 поля - Имя и Пароль - Кнопка Вход доступна - Ссылка "забыл пароль" - доступна |
... |
Пример тест кейса 2:
Название: Проверка отображения страницы
Действие: Открыть страницу
"Вход в систему"
Проверка: Проверьте, что отображаемая страница соответствует странице на картинке 1 (и
прилагаем изображение страницы "Вход в систему")
В примере 1 и 2 покрытие будет одинаковым, но вот время, которое потребуется для прохождения, будет разным. Мне кажется, что второй пример будет даже нагляднее.
На нашем сайте вы также сможете найти пример оформления тест кейса
В дополнение хочется сказать, что решение о виде тест кейса и детализации его описания принимает человек, ответственный за его создание - Тест Дизайнер или Тест Аналитик, обладающий необходимым опытом, и который знает тест дизайн не по наслышке и имеет опыт практического применения техник тест дизайна. Во многих компаниях эта роль не выделяется отдельно, а доверяется обычным тестировщикам , что в случае недостаточной квалификации может привести к переписке тест кейсов.
Вывод
В заключение скажу, для того чтобы команда тестирования работала сплоченно и не отвлекалась по вопросам оформления тест кейсов, у всех должен быть единый шаблон или подход к их написанию. То, что предлагаем мы - это структура PreConditions, Test Case Description, PostConditions, и уже ваше личное дело - пользоваться ей или придумать свой "велосипед".
