Опишите структуру тест-кейса, детализацию описания.
Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим:
Верно ли наше решение?
Ответ:
Каждый тест кейс обычно состоит из трёх частей:
PreConditions - Список действий, которые приводят систему к состоянию, пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description - Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям PostConditions - Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state)
Post Conditions не является обязательной частью. Это скорее всего - правило хорошего тона: "намусорил - убери за собой". Это особенно актуально при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов.
Есть много подходов к написанию тестовых случаев, соответственно, уровень детализации при различных подходах разный.
Но есть общепринятое правило, что уровень детализации тест кейсов должен быть таков, чтобы обеспечивать разумное соотношение времени прохождения к тестовому покрытию. Т.е. до тех пор пока покрытие тестами определенного функционала не меняется, можно уменьшать детализацию тест кейсов.
Пример тест-кейса:
-1-
Название: Проверка отображения главного меню программы
Действие: Запустить программу -> ввести учетные данные -> нажать кнопку "Войти"
Проверка: Проверить, что меню программы отображается согласно спецификации (стр. 23)
-2-
Действие: запустить программу -> ввести имя пользователя и пароль
Ожидаемый результат:
- Окно "Вход в систему" открыто
- Название окна - Вход в систему
- Название программы отображается в правом верхнем углу
- На форме 2 поля - Имя и Пароль
- Кнопка Вход доступна
Тестовый результат: .......
В примере 1 и 2 покрытие будет одинаковым, но вот время, которое потребуется для прохождения, будет разным.
Решение о виде тест кейса и детализации его описания принимает человек, ответственный за его создание - Тест Дизайнер или Тест Аналитик, обладающий необходимым опытом, и который знает тест дизайн не по наслышке и имеет опыт практического применения техник тест дизайна. Во многих компаниях эта роль не выделяется отдельно, а доверяется обычным тестировщикам , что в случае недостаточной квалификации может привести к переписке тест кейсов.
Опишите структуру тест-кейса, детализацию описания.
Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим:
Верно ли наше решение?
Ответ:
Каждый тест кейс обычно состоит из трёх частей:
PreConditions - Список действий, которые приводят систему к состоянию, пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description - Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям PostConditions - Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state)
Post Conditions не является обязательной частью. Это скорее всего - правило хорошего тона: "намусорил - убери за собой". Это особенно актуально при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов.
Есть много подходов к написанию тестовых случаев, соответственно, уровень детализации при различных подходах разный.
Но есть общепринятое правило, что уровень детализации тест кейсов должен быть таков, чтобы обеспечивать разумное соотношение времени прохождения к тестовому покрытию. Т.е. до тех пор пока покрытие тестами определенного функционала не меняется, можно уменьшать детализацию тест кейсов.
Пример тест-кейса:
-1-
Название: Проверка отображения главного меню программы
Действие: Запустить программу -> ввести учетные данные -> нажать кнопку "Войти"
Проверка: Проверить, что меню программы отображается согласно спецификации (стр. 23)
-2-
Действие: запустить программу -> ввести имя пользователя и пароль
Ожидаемый результат:
- Окно "Вход в систему" открыто
- Название окна - Вход в систему
- Название программы отображается в правом верхнем углу
- На форме 2 поля - Имя и Пароль
- Кнопка Вход доступна
Тестовый результат: .......
В примере 1 и 2 покрытие будет одинаковым, но вот время, которое потребуется для прохождения, будет разным.
Решение о виде тест кейса и детализации его описания принимает человек, ответственный за его создание - Тест Дизайнер или Тест Аналитик, обладающий необходимым опытом, и который знает тест дизайн не по наслышке и имеет опыт практического применения техник тест дизайна. Во многих компаниях эта роль не выделяется отдельно, а доверяется обычным тестировщикам , что в случае недостаточной квалификации может привести к переписке тест кейсов.