Один тест-кейс - одна проверка ?

Зависит от того как у вас организован процесс, какое видение кейсов у вашего руководства, для кого нужны эти кейсы и т.д.

В моем проекте я бы даже не подумала написать первый тест: " заходим на страницу создания и проверяем, что все поля присутствуют на странице и они все доступны для ввода данных ", т.к. во втором тесте мы это и так проверим при заполнении полей, а излишние тесты еще никому не помогали :)

Если следовать вашей логике надо сделать 100500 тестов, в которых будет проверяться каждое поле в отдельности, при чем в одних тестах будет проверяться, что эти поля есть, в другом тесте будет проверка заполнения поля, в третьем тесте будет проверка отображения поля на этапе проверки введенных данных и т.п. Можно сделать наиатомарнейшие тесты, только спросите себя - вам это точно надо? И если да, то зачем? :)

Не следует заставлять тестировщиков тестировать быстрее. Что может быть хуже испуганных, усталых, цинично настроенных тестировщиков? ----------------- Хорошо, когда человек заводит баги . Плохо, когда баги заводят человека (с) ----------------- Проект для начинающих тестировщиков Хомячки

#3 Dananas

ФИО: Егор

Тут можно посмотреть и вдоль и поперек =)

По большому счету, если разделять сценарии по видам тестирования (УИ и функциональное), то да, здесь будет два разных сценария. Проверяющих разные вещи.

Я придерживаюсь 2 разным правилам: "Один чек лист - одно требование" или "Один шаг в сценарии - одно требование". Соответственно, один сценарий может содержать в себе много всяких проверок. Но опять же, нужно стараться сценарии писать под проверку одного типа тестирования, а не все в куче (ибо, например, функционал ломается гораздо чаще чем УИ, следовательно, каждый раз проверять доступность полей - лишняя трата времени при функциональном тестировании).

#4 breakmt

Город: Санкт-Петербург

В первом тест кейсе вашего примера нет никакого смысла, т.к. если поля будут отстутствовать/недоступны для ввода - зафейлится второй тест кейс

#5 Dananas

ФИО: Егор

Ох не согласен! Я могу авторизоваться пост запросом, минуя интерфейс в общем.

А могу воспользоваться не этим интерфейсом, а другим.

Много чего могло поменяться, так что не проверять это - нельзя. Другое дело как часто и с чем комбинировать

#6 clipsa

ФИО: Ермолаева Ольга
Город: Москва

Егор, позвольте с вами не согласиться.

Исходя из того, что написал ТС: " Во втором тест-кейсе мы заходим на страницу добавления пользователя, заполняем все поля валидными данными, сохраняем и проверяем, что отобразилась страница пользователя с введенными ранее данными плюс дополнительные поля ", второй тест в любом случае проверит то, что проверил бы первый кейс.

#7 Dananas

ФИО: Егор

А вот это проблема разделения сценариев по типам проверок у ТС. То есть: 1. Первая проверка - Верификация полей, всплывающие подсказки, ошибки и прочее. 2. Вторая проверка - использование указанной информации корректным образом.

Если упираться на то, что написал ТС, то да, нужен только второй тест-кейс =))

#8 clipsa

ФИО: Ермолаева Ольга
Город: Москва

Кроме того, что написал ТС у нас в данном случае других данных нет, поэтому зачем додумывать :)

#9 Vad1m198

ФИО: Вадим

Не стоит так придератся к приведенным примерам. Вопрос в другом: сколько проверок в себя может включать тест-кейс?.

Когда я писал "Один тест-кейс - одна проверка", я имел ввиду, что в каждом кейсе мы сначала приводим систему в некое ОДНО состояние и из этого состояния делаем проверки. Если в тест кейсе мы делаем проверки для нескольких состояний, то это будут разные тест-кейсы.

Например, если розширить второй тест кейс, после сохранения появляется возможность редактировать профиль нажатием на кнопку "Редактировать" (некие поля стают доступными для изменения) -> сохранить изменения кнопкою "Сохранить" -> и наконец удалить профайл кнопкою "Удалить"

Допустимо ли эти все действия и проверки на каждом шаге "запихнуть" в один кейс?

#10 Dananas

ФИО: Егор

Смотри, для чего нужен сценарий (если воспринимать тест-кейс как последовательность шагов, а не как один чек-лист)? Я вижу глобально 3 ответа: 1. Ряд действий для воспроизведения какого-то конкретного случая (например, кнопочка ломается если сделать так, так и еще вот так).

2. Объединение ЧЛ/требований и прочего в единый кейс для простоты управления проверкой (например, твоя задача провести регресс обычного калькулятора. Следовательно, было бы логично запихнуть проверку всех мат действий в один сценарий, навигацию по меню в другой и т.д.)

3. Для автотестов (что нам не нужно).

В первом случае, у тебя будет проверяться одно требование в одной кейсе.

Во втором случае у тебя будет проверяться много требований в одном кейсе.

Соответственно, фразу "Один тест-кейс - одна проверка" за постулат лучше не брать. Я же практикую либо "Один ЧЛ - одно требование", либо "Один шаг в сценарии - одно требование".

Я попал ответом в вопрос? =)

#11 clipsa

ФИО: Ермолаева Ольга
Город: Москва

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

Почему именно кейсы, а не чек-лист? (потому что заказчик требует, чтобы на проекте были кейсы, потому что кейсы будут выполнять роль отсутствующей/неполной документации, потому что проходить кейсы будут неопытные студенты и т.п.)

Как и кто будет тестировать по этим кейсам? (опытные тестеры, неопытные студенты, заказчики во время приемочного тестирования и т.п.)

Что вам в итоге этими кейсами надо проверить? (функциональность - внутренности, формочки, все вместе)

Большой ли проект? (на огромных проектах если расписывать один кейс-одна проверка - кейсов будет туева хуча, поэтому допускают несколько проверок в кейсе, чтобы не приводить каждый раз систему в "начальное положение для кейса", в каких-то маленьких проектах возможно имеет смысл расписывать отдельно каждую проверку)

В любом случае при тест-дизайне надо отталкиваться от здравого смысла и текущих условий на проекте

📎📎📎📎📎📎📎📎📎📎