Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!
Недавно на собеседовании QA trainee задали вопрос «Когда нужно использовать checklist, а когда test case?». Гугл пока что не помог, может вы поможете) Ответила, что я бы использовала и то и то, но специалист добавила этот вопрос к тем, которые я не знаю. Подскажите, пожалуйста
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 месяца у них станет нечего делать и ты пойдёшь дальше. Поэтому тебе и не дают оффер.
А ещё может просто не повезти,ты можешь затупить(вот просто ты знаешь ответ и вечером ты сидишь и думаешь какого чёрта ты так ответил, ведь ты же знаешь правильный ответ) или ответить на свой вопрос. И на другом таком же собесе,только в другой компании ты будешь сиять, а не блекнуть)
Когда я искал работу я прикинул себе устроиться где-то на
Так что развивайтесь,учитесь и не парьтесь в тему отказов/неправильных ответов на собесах/плохих тестовых и т.д. Try harder)
Этот вопрос из ряда вопросов «аби не мовчки», смысл спрашивать, если в конторе уже всё устоялось.Либо чел большой поклонник ISQTB, теоретик не более!
Я би добавив, що checklist юзати зручно для UI елементів.
1. Зависит от того как принято в рамках компании
2. Зависит от домена, в медицине будет и документация, и детальные тест кейсы, а в WP информаниционниках будут чек листы
3. Есть такое понятик как deliverables, что прописали в контракте то и делают
4. Часто спрашивают у клиента что ему надо, теск кейсы продают дороже
5. Может быть микс. Если делать регресию то юзают тест кейсы, если смоук — то чеклист
В принципе, ответ, очень близкий к истине уже дан. Вообще, очень рекомендую автору изучить Syllabus ISTQB for Foundation level и их же Glossary Это, на мой взгляд, минимум, который должен знать любой тестировщик. (За исключением разделов
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 раза больше времени, чем прохождение (тестирование фичи). то есть, тест кейсы дорогие в создании и поддержке. если у вас нет текучки кадров — можно обойтись без них (на собеседовании такого говорить нельзя, а то побьют).
В мене була ідентична ситуація як в автора, тільки я відповів що чекліст це як зміст в книжці, а тесткейс це конкретний випадок, де описуються вхідні дані і процедура проходження. І що використовував би одне і друге, тому що це більше взаємодоповнюючі елементи, а не взаємозамінні. Правильно чи ні не сказали (думаю як і авторші, про відмітку в «неправильних» відповідях сама допридумала) але подивились як на мале пиво, тому думаю що така відповідь не підійшла.
Це якщо брати теоретичний випадок, а не конкретний, тобто немає даних ні про об’єм тестування, ні про команду, час і тд.
Відповідь була помилкова?
Та звідки я знаю — кожен розуміє в міру власної розбещеності. В кожної контори власні традиції — що, як та навіщо писать. Головне — щоб ця уся писанина допомагала роботі, а не час гаяла.
Я не допридумывала. В конце мне прислали все неправильные ответы и темы, которые нужно подтянуть и узнать) Этот был в их числе)
Рабингранат Кагор
Dmytro Pozhydaiev
Дмитрий Павлов
атата
Дмитрий Павлов
yuraman
Oleksandr Semeniuk
Ievgen Rud
Luci
Сергій Мацюпа
Denys Poltorak
Denys Poltorak
16 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів