Просто о чек-листах

[@svetlanamazhaykina6918]

Спасибо за Ваш труд! Коммент в поддержку канала.

[@qabuggage]

И вам спасибо)

[@hajkya]

Узнал много нового для себя! Спасибо большое, Елена!

[@sr480]

Просто и понятно! Спасибо

[@qabuggage]

Рады, что понравилось!

[@XPyCT_HOCKOB]

Огонь :)

[@samoiloff90]

Контент огонь! Продолжай)

[@KibaFinisT]

Конец трейлера - Лена грозится записывать видео одна. Следующее видео - Лена одна - угроза исполнена?)

[@qabuggage]

😂😁😄 Пока угроза в действие не приведена)) Выпуски будут выходить либо от Лены, либо от Ани.

[@anastasiavolkova3495]

Лена сказала - Лена сделала 😆

[@МарияСухорукова-я2н]

Спасибо за видео❤

[@МаксимИванов-м7п]

Елена, привет! А если в тестовом задании просят исчерпывающую проверку формы провести, то всевозможные негативные сценарии являются необходимыми в чек листе по всем полям? Впервые встретил, что только позитивные проверки проводят (и тестовые данные на границах не все).

[@qabuggage]

Предположу, что сама формулировка "исчерпывающая проверка формы" говорит о том, что вам нужно описать все проверки/тест-кейсы - и позитивные, и негативные. Если вы пишите чек-лист, то формат описания будет зависеть от требований. Например, если по требованиям ошибка отображается в виде текста под полем, можно написать 1 негативный сценарий/проверку/тест-кейс вида "Создать объект с пустыми обязательными полями". Если, например, по требованиям кнопка создания недоступна, пока все обязательные поля не будут заполнены, то лучше проверять отдельно каждое поле. Например, "Заполнить все обязательные поля, кроме Имя - кнопка создания студента недоступна". Еще пару мыслей от меня, если бы я вам дала это тестовое задание (учтите, что в вашем случае это необязательно так). Если у вас есть вопросы по логике работы формы, лучше задайте их. Это покажет вашу способность тестировать требования или выявлять их при отсутствии требований. Обычно при помощи тестовых заданий проверяется способность генерировать тестовые случаи и расставлять им приоритеты, неважно, в какой форме они в итоге представляются - тест-кейсы или чек-листы. Так что указывайте все, что нагенерируете, но без дублирования (когда в разных кейсах проверяется по сути одно и то же). Надеюсь, смогла ответить на ваш вопрос.

[@МаксимИванов-м7п]

@@qabuggage Благодарю за такой подробный и развернутый ответ!

[@dinastia69]

Елена, привет! Спасибо за крутой контент, а теперь глупый вопрос от новичка....Почему при обучении нас учат писать проверки на позитивные и негативные проверки, но пообщавшись с практикующими тестерами, они в один голос твердят, что в тест- кейсах не пишут проверки на негативный сценарий? Говорят, что пишут кейсы лишь на позитивные, а сами проверки осуществляют и на позитивный сценарий и на негативный...Экономия времени? Но как же они потом вспомнят, что из негативного прогнали, а что нет?

[@qabuggage]

Добрый день. На курсах вас обучают лучшим практикам. Могу предположить, что работающие тестировщики могут отходить от них по разным причинам - не хватает квалификации, знаний, думают, что экономят время (хотя это спорно), на проекте выделяют мало времени на тестирование и тестировщики не пытаются на это влиять, поэтому экономят на тест-дизайне. Возможно, на проекте "так принято". Вы описали верно проблему - в уме все удержать невозможно, особенно для больших задач. Поэтому риски пропуска багов повышаются - как из-за того, что тестировщик не придумал в уме нужный негативный сценарий, так и из-за того, что забыл его проверить. Насчёт "в один голос утверждают" - я сталкивалась с другой картиной. Или тестировщики полноценно пишут чек-листы/тест-кейсы, или не пишут их вовсе. Моя позиция - писать чек-листы. Кстати, в нашем руководстве по построению процесса тестирования мы как раз и даём такой совет и описываем, исходя из нашего опыта, преимущества раннего проектирования чек-листов, а также минусы тестирования без тест-кейсов или чек-листов. Если остались вопросы, задавайте)

[@АлексейТарасов-н6ю]

И то и то используем) В зависимости от ситуации!

[@qabuggage]

Я нередко использую комбинацию чек-листов и тест-кейсов. Например, основной положительный кейс - делаю именно в виде тест-кейса, а не проверки в чек-листе. Или описываю в виде тест-кейса тестовые случаи с большим количеством шагов, которые просто невозможно сформулировать кратко в виде проверки. Мое правило - если проверка занимает 3 строки, желательно переформулировать ее в тест-кейс. (Елена Поплоухина)

[@anastasiavolkova3495]

А где ссылка на шаблоны? Спасибо за видео, очень интересно )

[@Lily_Lika]

Мы не пишем тест-кейсы и чек-листы, потому что qa lead считает, что в этом не необходимости. Мы пишем тест-скрипт, где описываем что хотим проверить/проверили, дополнительная информация. Это короче чек-листа.

[@qabuggage]

Могу предположить, что ваш тест-скрипт - это удобная для вашей команды и проекта форма представления чек-листа (т.е. списка проверок). По чек-листам нет единых шаблонов, как по тест-кейсам. Я делюсь тем форматом, которым пользуюсь. P.S. По видео на канале вы наверняка поняли, что я вижу необходимость в написании чек-листов (или в редких случаях, тест-кейсов) :)