Писал достаточно быстро, за мисочкой супа, но надеюсь я смог раскрыть мысль. :)

вы о чем вообще, какие мотивы ? какие-то не логичные выводы вы делаете уважаемый для незнакомого человека игнорируя мои слова выше

Мысль раскрыта. Я просто уточнил за атомарность. Меня смутило именно "одну функцию продукта". Я бы предложил вариант "тест-кейс должен иметь одну цель", или как-то так.

Кстати, да. Эта формулировка лучше подходит.

Не хочу развивать срач. За модой я не слежу, выгоды я не вижу, ЧСВ чешу иными способами, нежели унижая людей за отсутствие каких-либо знаний. Говорю исключительно за себя, и мне кажется, что этого достаточно.

На сколько я понимаю, каким должен быть тест-кейс:
1. Написанным по шаблону который был дан или если его нет то по базовому шаблону столбов
2. Тест-кейс не должен превышать 10 шагов (но есть исключения)
3. Он должен содержать максимально понятную информацию (конкретика должна быть)
4. Должен быть описан полный цикл тест кейса, а не на половину
5. Шаги должны быть описаны лаоанично и понятными (без двумыслия)
6. 1 тест кейс может покрыть 1 и более функционал продукта, зависит от проекта, но желательно чтобы покрывал 1 функциональное требование

💪😊 от души!

дык никто срач и не разводит, просто у вас своё мнение у меня своё и это нормально я думаю

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

Anton раскрывая"понятность".

- Наличие ссылок на инструментарий. Если у нас требуются утилиты/скрипты/любые вспомогательные инструменты, то на них должна быть указана ссылка (либо они могут быть прикреплены прямо к тест-кейсу). Это действует только в том случае, если вы в команде не условились поднять какой-либо сервер с этими самыми у утилитами и хранить всё там;

- Наличие ожидаемого результата. Вам нужно всегда указывать то, что тестировщик должен получить на выходе. Иногда это интуитивно понятно, но у всех мышление разное и кто-то может эту очевидность не заметить. :)

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

- Наличие обоснования величин, выбранных для теста, если таковые имеются. Если брать всеми любимый карандаш, то можно сделать тест на то как долго он пишет. И нельзя в тест-кейсе просто указать "написать карандашом 2 листа". Любой другой человек задаст резонный вопрос "А почему не три листа?".

- Отсутствие сленга и никем не используемых терминов в вашей группе.

Это то, что сходу придумалось. :)

💪😊 спасибо, теперь буду знать.

Уверен, что список можно расширить, но пока у меня нет идей и времени. ))

а можете про наличие обоснований по подробнее ? как это на примере карандаша ?

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

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

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

Возможно, я не совсем верно Вас понял касательно обоснования. Оставить в кейсе ссылку на требование -- хороший тон.

да, наверное @Keane это и имел ввиду, что какие-то ссылки на пункты из ФТ, просто по другому я вот не знаю как ещё

Как определить момент начала тестирования? Не когда начинать, а именно момент начала. Когда описаны все варианты использования?🤔

Тестирования чего?

ПО

Да, всё так. Чаще всего это обоснование должно быть массивным и в тест-кейс его пихать неудобно, конечно же.

Но оно где-то должно быть, чтобы тестировщик (особенно новый) понимал, почему тут написано 2 листа, а не 3 или 200.