Раздел: Тестирование > Тестовые Артефакты > Тестовый случай (Test Case)
Тестовый случай (Test Case)
Тестовый случай (Test Case) - это совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Под тест кейсом понимается структура вида:
Action > Expected Result > Test Result
Пример:
| Action |
Expected Result |
Test Result |
| Open page "login" |
Login page is opened |
Passed |
Структура Тестовых Случаев (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 |
| 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 |
| PreConditions | ||
| do A1 | verify B1 | passed |
| do A2 | verify B2 | failed |
| Test Case Description: | ||
| do A3 | verify B3 | blocked |
| PostConditions | ||
Детализация описания тест кейсов (Test Case Details Elaboration)
Бытует много разных мнений об уровне детализации при написании тест кейсов, а также количестве проверок в одном тест кейсе. Все они по своему правильные. Мое мнение, что уровень детализации тест кейсов должен быть таков, чтобы обеспечивать разумное соотношение времени прохождения к тестовому покрытию. Т.е. до тех пор пока покрытие тестами определенного функционала не меняется, можно уменьшать детализацию тест кейсов.
Пример тест кейса 1:
Проверка отображения страницы |
||
Действие |
Ожидаемый результат |
Результат теста |
Открыть страницу "Вход в систему" |
- Окно "Вход в систему" открыто |
... |
Пример тест кейса 2:
Название: Проверка отображения страницы
Действие: Открыть страницу "Вход в систему"
Проверка: Проверьте, что отображаемая страница соответствует странице на картинке 1 (и прилагаем изображение страницы "Вход в систему")
В примере 1 и 2 покрытие будет одинаковым, но вот время, которое потребуется для прохождения, будет разным. Мне кажется, что второй пример будет даже нагляднее.
В дополнение хочется сказать, что решение о виде тест кейса и детализации его описания принимает человек, ответственный за его создание - Тест Дизайнер или Тест Аналитик, обладающий необходимым опытом, и который знает техники тест дизайна не по наслышке и имеет опыт практического применения техник тест дизайна. Во многих компаниях эта роль не выделяется отдельно, а доверяется обычным тестировщикам , что в случае недостаточной квалификации может привести к переписке тест кейсов.
Вывод
В заключении скажу, для того чтобы команда тестирования работала сплоченно и не отвлекалась по вопросам оформления тест кейсов, у всех должен быть единый шаблон или подход к их написанию. То, что предлагаем мы - это структура PreConditions, Test Case Description, PostConditions, и уже ваше личное дела - пользоваться ей или придумать свой "велосипед".
