Сообщений в теме: 12

[Vad1m198]

Во время разработки тест кейсов придерживаитесь ли Вы правила: "Один тест-кейс - одна проверка" ?

 

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

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

[clipsa]

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

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

 

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

[Dananas]

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

Вдоль:

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

 

Поперек:

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

[breakmt]

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

[Dananas]

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

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

 

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

[clipsa]

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

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

[Dananas]

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

 

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

[clipsa]

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

[Vad1m198]

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

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

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

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

[Dananas]

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

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

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

 

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

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

 

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

 

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

[clipsa]

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

 

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

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

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

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

 

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

[vinogradoff]

Существуют разные стратегии. Я предпочитаю писать маленькие тест-кейсы с одной проверкой, в очень сжатом виде (http://sqadays.com/en/talk/25572 - "no-test-cases")

 

Если писать большие и полноценные, я бы объединял проверки, потому что иначе уже больно много букв.

[Dananas]

 

 

Я предпочитаю писать маленькие тест-кейсы с одной проверкой

 

А разве это не то же самое что чеклист?