Автор Nuxt.JS вперше в Україні на конференції JavaScript fwdays | 14 березня, Київ
×Закрыть

Вопрос на собеседовании QA trainee

Недавно на собеседовании QA trainee задали вопрос «Когда нужно использовать checklist, а когда test case?». Гугл пока что не помог, может вы поможете) Ответила, что я бы использовала и то и то, но специалист добавила этот вопрос к тем, которые я не знаю. Подскажите, пожалуйста

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Checklist-based Testing

Stupid term, but it is very human...

If you need to dig a hole in the mother Earth, you will need a spade. And the process of creating a hole will be called ’to dig’, not something like ’spade digging’. Because it doesn’t matter, how you will dig a hole. You will use a spade, of course. Or your hands. When you will use in testing a checklist, this is still the same testing, right?!

But if you want to feel yourself less dumb, you can say, that you will use the Checklist-based Testing. Something unusual! Something great! A new type of testing!

And if someone will interfere, just tell him following magic words: “A checklist-based Testing is a test design technique whereby the experienced tester uses a high-level list of items to be noted, checked, or remembered, or a set of rules or criteria against which a product has to be verifed. Step aside, whiffet!”

All the chicks will starve to death admiring you, my ass.

Чек-лист — список чего-то, что надо выполнить, иногда строго последовательно. Проверил пункт — отметил галочкой (to check).

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

Любой тест-кейс является чек-листом.

Любой перечень тест-кейсов, которые надо выполнить, является чек-листом.

Любой перечень функций, которые надо проверить в ПО, является чек-листом.

Любой список «РАССТРЕЛЯТЬ!» за подписью лично тов. Сталина — является чек-листом.

Да любой чек-лист является чек-листом! И даже список чек-листов является чек-листом!

Гугл правильно делает, что не помогает. Считать тест-кейсы и чек-листы отдельными артефактами — очень глупо.

Поэтому правильный ответ на

«Когда нужно использовать checklist, а когда test case?»

прост: — тогда, когда это нужно.

На самом деле бывают ситуации, когда на собеседовании ты даёшь правильный ответ, а интервьюер говорит, что твой ответ неправильный. У трейни/джунов такое редко, но бывает. И если вы даёте «неправильный» ответ не переходите на следующий, покажите ход своих мыслей и объясните почему вы дали такой ответ и считаете его правильным. Умение мыслить и доносить своё мнение важно. Также, т.к вы идёте на начальную позицию важно показать, что вы если что-то не знаете, то моментально это закрываете, а не откладываете в ящик на потом.

В тему чек листа и тест-кейса...Тут можно ооооочень много рассуждать на тему этого вопроса(по типу как протестировать карандаш на 80+листов).
Что такое чек-лист? Для меня это высокоуровневое описание функционала, которое надо протестировать. Например
Протестировать корзину:
-проверить,что можно добавить
-Можно удалить
-При нажатии оплатить переходит на функционал оплаты
-Нельзя добавить неактивные товары
-Нельзя добавить товары,которых нет в наличии
и т.д и т.п

Что такое тест-кейс? Это подробный сценарий проведения одного тестового случая.
Например, проверить возможность добавления товара в корзину из промо банера.
И там описывается подготовка-в своей системе подготовьте баннер с кнопкой добавления в корзину.
1.Выполнение-зайдите на site.com
2. Авторизуйтесь, как пользователь
3. На банере(название/способ найти его) нажмите «купить»
Ожидаемый результат: пользователь видит сообщение «товар успешно добавлен в корзину». На иконке корзины отображается цифра текущего количества товаров в корзине.

То есть чеклист нужен для быстрого тестирования системы(в основном такое тестирование называют sanity-на вменяемость). Когда нет времени прогнать всё и тщательно, а какие-то гарантии нужно дать, что всё работает(в большинстве своём стараются покрыть не наибольшее количество разного функционала,но по чуть-чуть, а наоборот-самый важный и критичный протестировать и подёргать лучше) тогда берут чеклисты. А тест-кейс(если один тест-кейс), то это для проверки одного сценария...И как по мне вопрос поставлен некорректно. Это как спросить чем отличается страус от камня...
Можно было сказать, что из тест-кейсов можно составить test-suite и тогда можно сравнивать-когда использовать test-suite, а когда чеклист.

Опять же, я думаю, что ко всему, что я сказал можно придраться. Но фишка в том, что я смогу защитить своё мнение аргументами и доводами. И это важно) Уверенность в своих словах и умение отстаивать свою правоту.

Удачи вам в поисках)

Ага ага, ок. Нам насрати що ви можете щось доказати, ми вам передзвонимо

«Нам насрати що ви можете» очень не рекомендую задерживаться в таких конторах. С первой работой,конечно, понятно-не ты выбираешь её, а она тебя, но очень советую знать себе цену и показывать, что у тебя тоже есть зубы.
И я об этом много парился, когда и сам искал работу:у меня и англа норм была и технически всё хорошо, работал с кодом(написал на движке пару простых игрушек), мог в автотесты, денег немного просил. И часто получал отказы. НО. Есть такое понятие, как overqualified. Ребята ищут человека, который не хочет рости и развиваться, будет 2 года сидеть на этом же проекте и за 2 года с 400 баксов выростет до 500. И если видят, что ты реально шаришь, учишься и развиваешься, то тебе через 3 месяца у них станет нечего делать и ты пойдёшь дальше. Поэтому тебе и не дают оффер.
А ещё может просто не повезти,ты можешь затупить(вот просто ты знаешь ответ и вечером ты сидишь и думаешь какого чёрта ты так ответил, ведь ты же знаешь правильный ответ) или ответить на свой вопрос. И на другом таком же собесе,только в другой компании ты будешь сиять, а не блекнуть)
Когда я искал работу я прикинул себе устроиться где-то на 10-м собеседовании. Пробовался на безоплатную стажировку в SoftServe, но технический тест я завалил(помойму там задачи на логику были и одну я точно помню, что прочёл условие, но поставил себе свой вопрос,ответил на него, а потом когда результаты пришли понял, что отвечал не на тот вопрос). Соответственно не прошел. А через 2 недели после этого фейла собес на 7-8 я попал в замечательную компанию Levi9, меня собеседовали на трейни на внутренний проект, но когда я вышел первый день выяснилось, что меня отправили на уже «боевой» проект с заказчиком, решили, что у меня хватает сил. И таки да, была поддержка, да и сам не глупый, я справился.
Так что развивайтесь,учитесь и не парьтесь в тему отказов/неправильных ответов на собесах/плохих тестовых и т.д. Try harder)

Этот вопрос из ряда вопросов «аби не мовчки», смысл спрашивать, если в конторе уже всё устоялось.Либо чел большой поклонник ISQTB, теоретик не более!

Я би добавив, що checklist юзати зручно для UI елементів.

1. Зависит от того как принято в рамках компании
2. Зависит от домена, в медицине будет и документация, и детальные тест кейсы, а в WP информаниционниках будут чек листы
3. Есть такое понятик как deliverables, что прописали в контракте то и делают
4. Часто спрашивают у клиента что ему надо, теск кейсы продают дороже
5. Может быть микс. Если делать регресию то юзают тест кейсы, если смоук — то чеклист

В принципе, ответ, очень близкий к истине уже дан. Вообще, очень рекомендую автору изучить Syllabus ISTQB for Foundation level и их же Glossary Это, на мой взгляд, минимум, который должен знать любой тестировщик. (За исключением разделов 3.2.1-3.2.3, 5, 6 — которые либо вообще мало где нужны либо просто nice to have)


Checklist — a set of ideas for testing (for writing test cases).
Test case — a set of preconditions, inputs, actions (where applicable), expected results and postconditions, developed based on test conditions to verify a particular property or behavior of the software.
То есть в идеальном мире Checklist item == Test Case Summary field.
В хорошем мире Checklist item === Software Requirement (1 item, look „traceability matrix”).
В реальном мире Checklist item — то на чем может закончиться test procedure specification.
Соотв.

когда использовать checklist

 — 1. во время Exploratory testing 2. „когда нужно все очень быстро” (и это снова будет Exploratory testing) 3. когда делаем отчетность по совсем-уже-быстрому-ad-hoc, табличка „а что мы/вы тестировали эээ?”
При „нормальном жирном тестировании” (регрессии бгг) — только test case based.

На ISTQB compliance не претендую есличто.

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

тест кейсы требуют постоянных апдейтов пареллельно развитию фич, и написание тест кейса занимает в 3 раза больше времени, чем прохождение (тестирование фичи). то есть, тест кейсы дорогие в создании и поддержке. если у вас нет текучки кадров — можно обойтись без них (на собеседовании такого говорить нельзя, а то побьют).

В мене була ідентична ситуація як в автора, тільки я відповів що чекліст це як зміст в книжці, а тесткейс це конкретний випадок, де описуються вхідні дані і процедура проходження. І що використовував би одне і друге, тому що це більше взаємодоповнюючі елементи, а не взаємозамінні. Правильно чи ні не сказали (думаю як і авторші, про відмітку в «неправильних» відповідях сама допридумала) але подивились як на мале пиво, тому думаю що така відповідь не підійшла.
Це якщо брати теоретичний випадок, а не конкретний, тобто немає даних ні про об’єм тестування, ні про команду, час і тд.
Відповідь була помилкова?

Та звідки я знаю — кожен розуміє в міру власної розбещеності. В кожної контори власні традиції — що, як та навіщо писать. Головне — щоб ця уся писанина допомагала роботі, а не час гаяла.

Я не допридумывала. В конце мне прислали все неправильные ответы и темы, которые нужно подтянуть и узнать) Этот был в их числе)

Подписаться на комментарии