1 .ID - уникальный номер
Обычно проставляется автоматически в системах хранения тест-кейсов.
2. Краткое описание тест-кейса (Name)
Название тест-кейса должно быть коротким и понятным. Оба эти слова важны.
Если мы сделаем название только коротким, то в таких кейсах будет очень сложно ориентироваться.
Например, мы проверяем регистрацию и называем тест-кейс: “Проверить успешную регистрацию”. Вроде логично, но такое название включает в себя проверку регистрации по нескольким полям. И получается, что название не информативно.
Если делать название тест-кейса слишком длинным, то его будет очень сложно читать, например: “Проверить правильную регистрацию, когда вводим логин латинскими буквами без цифр и пробелов с паролем из цифр”.
Такое название неудобно читать. Плюс некоторые инструменты хранения тест-кейсов могут обрезать длинные названия.
Что делать? Немного сократить название, убрать “Проверить” и слова, которые не несут важного смысла и получим следующее: “Регистрация с латинским логином”, “Регистрация с логином из цифр” и так далее.
3. Ссылка на требования — ссылка на требование или ТЗ, на основе которого был составлен тест-кейс
4. Автор тест-кейсы (Author) — тестировщик, который написал тест-кейс
5. Приоритет (Priority) — насколько важен этот тест-кейс, в какую очередь его стоит выполнять
6. Название/модуль/версия продукта (Component/Version) — описание ПО, на котором можно выполнить тест-кейс
7. Предварительные условия (pre-condition) — шаги, которые необходимо выполнить перед началом тестирования по этому тест-кейсу
8. Шаги (steps) — точная последовательно действий для выполнения проверки
Шаги должны быть четкими и понятными. В идеале их нужно писать так, чтобы понял даже человек, который видит проект и тестирование в первый раз. Четкие шаги снизят риски того, что тест-кейс будет неправильно понят, а соответственно и неправильно протестирован другими тестировщиками, особенно новичками, которые только пришли на проект. Скажу даже больше: иногда вы сами спустя какое-то время с трудом разбираете, что имели ввиду написав тот или иной шаг.
9. Ожидаемый результат (expected result) — что мы получаем после выполнения шагов
10. Приложения (attachments) — дополнительная информация, которая поможет выполнить тест-кейс, например, скриншоты, текстовые файлы и прочие файлы.
#QAглазамиДжуна_полезное #тестоваядокументация #QAглазамиДжуна_понятия #тесткейс
Обычно проставляется автоматически в системах хранения тест-кейсов.
2. Краткое описание тест-кейса (Name)
Название тест-кейса должно быть коротким и понятным. Оба эти слова важны.
Если мы сделаем название только коротким, то в таких кейсах будет очень сложно ориентироваться.
Например, мы проверяем регистрацию и называем тест-кейс: “Проверить успешную регистрацию”. Вроде логично, но такое название включает в себя проверку регистрации по нескольким полям. И получается, что название не информативно.
Если делать название тест-кейса слишком длинным, то его будет очень сложно читать, например: “Проверить правильную регистрацию, когда вводим логин латинскими буквами без цифр и пробелов с паролем из цифр”.
Такое название неудобно читать. Плюс некоторые инструменты хранения тест-кейсов могут обрезать длинные названия.
Что делать? Немного сократить название, убрать “Проверить” и слова, которые не несут важного смысла и получим следующее: “Регистрация с латинским логином”, “Регистрация с логином из цифр” и так далее.
3. Ссылка на требования — ссылка на требование или ТЗ, на основе которого был составлен тест-кейс
4. Автор тест-кейсы (Author) — тестировщик, который написал тест-кейс
5. Приоритет (Priority) — насколько важен этот тест-кейс, в какую очередь его стоит выполнять
6. Название/модуль/версия продукта (Component/Version) — описание ПО, на котором можно выполнить тест-кейс
7. Предварительные условия (pre-condition) — шаги, которые необходимо выполнить перед началом тестирования по этому тест-кейсу
8. Шаги (steps) — точная последовательно действий для выполнения проверки
Шаги должны быть четкими и понятными. В идеале их нужно писать так, чтобы понял даже человек, который видит проект и тестирование в первый раз. Четкие шаги снизят риски того, что тест-кейс будет неправильно понят, а соответственно и неправильно протестирован другими тестировщиками, особенно новичками, которые только пришли на проект. Скажу даже больше: иногда вы сами спустя какое-то время с трудом разбираете, что имели ввиду написав тот или иной шаг.
9. Ожидаемый результат (expected result) — что мы получаем после выполнения шагов
10. Приложения (attachments) — дополнительная информация, которая поможет выполнить тест-кейс, например, скриншоты, текстовые файлы и прочие файлы.
#QAглазамиДжуна_полезное #тестоваядокументация #QAглазамиДжуна_понятия #тесткейс