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

[Murat_Minsk]

Здравствуйте,
 
написал несколько тест-кейсов для стандартной формы, которая содержит два поля: Name и Email, но пока есть неуверенность по поводу, как полноты описания, так и "не добавил ли я чего лишнего":)

Пожалуйста оцените их качество.Возможно у кого-то будут замечания или предложения.
 

Заранее спасибо.

Прикрепленные файлы

•  PartOfTestCases.zip   13,88К   276 Количество загрузок:

[VinnieJohns]

Сразу два вопроса, не читая аттач: что такое "стандартная форма" и зачем ты для неё тест-кейсы написал, с какой целью? Откуда взял требования для этой "стандартной формы"?

 

По содержимому: 

- опечатки

- что я вижу в аттаче - есть не тест-кейсы, а чек-лист. Тоже неплохо, но давай называть вещи своими именами? ;)

- "ввод в поле ... граничных значений" - странные кейсы. Значение "0" проверяется в других строчках, а максимальное значение - ожидаемый результат: "не определено"? Oh, rly? ;) Значит ли это, что если при прогоне тест-кейса я не смогу ввести имя из 9000 символов, то я завожу багу? (Бо, граничные значения не определены и это ожидается == поле должно принимать строку любой длины)

- вставить любую web-ссылку - зачем? спецсимволы мы вставляем в других проверках, а для поля email ожидаемый результат этой проверки так вообще противоречит остальным.

- проверить на возможность инъекции - ввести символ <'> - и всё? А смысл тогда?

- почему email не принимает кириллицу? У меня вот, например, есть почта на @почта.рф

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

- тесты на email ожидают "отправку формы", а тесты на имя - перенаправление на другую страницу. У нас тут разные формы?

 

Общее впечатление: неаккуратно, как из-под палки делал.

Чего не хватает - ответа на вопрос "что и зачем мы тестируем?", поэтому всё внимание направлено на проверки отдельных полей, но нет понимания, что эти поля принадлежат одной форме. Было бы здорово увидеть в списке проверку ситуации, например, такой: оставили оба поля пустыми -> нажали "submit" (ну или чем мы там форму отправляем -> подсветились ОБА поля.

[irko]

По-моему, последние три пункта - по сути одна ситуация) или имеется, что "без доменной части" - email заканчивается @, "без локальной части" - начинается @?

 

Тестируется форма входа или форма регистрации? если форма регистрации, можно было б, например,  сделать проверку на уникальность name, email.

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

[Murat_Minsk]

Спасибо за ответы,

 

Сразу два вопроса, не читая аттач: что такое "стандартная форма" и зачем ты для неё тест-кейсы написал, с какой целью? Откуда взял требования для этой "стандартной формы"?

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

 

- опечатки

эта да, сорри

 

- вставить любую web-ссылку - зачем? спецсимволы мы вставляем в других проверках, а для поля email ожидаемый результат этой проверки так вообще противоречит остальным.

согласен, это я лишнее добавил.

 

- проверить на возможность инъекции - ввести символ <'> - и всё? А смысл тогда?

тут имеется ввиду проверить поле на возможность sql инъекции. В случае, если она возможна, то символ «’» даст ошибку, а значит инъекция возможна. На мой взгляд это достаточный признак того, что поле используется в запросе без обработки, но возможно я что-то упускаю.

 

- почему email не принимает кириллицу? У меня вот, например, есть почта на @почта.рф

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

 

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

Для этой формы - да.

 

- "ввод в поле ... граничных значений" - странные кейсы. Значение "0" проверяется в других строчках, а максимальное значение - ожидаемый результат: "не определено"? Oh, rly? ;) Значит ли это, что если при прогоне тест-кейса я не смогу ввести имя из 9000 символов, то я завожу багу? (Бо, граничные значения не определены и это ожидается == поле должно принимать строку любой длины)

да нужно было это уточнить - как таковых значений ограничивающих количество символов в ТЗ у меня нет(тк ТЗ у меня тоже нет  ), в html - они также не установлены, и на практике я смог ввести в поле достаточно большое количество символов(больше 500), соответсвенно я написал, что значения не определены - возможно стоит ввести (для моей тестовый ситуации) какое-то тестовое максимально возможное число символов, и проверить ввод количества символ как равное этому числу, так и больше его(негативный сценарий) - конечно, что это будет возможно, но для непродакшен тесткейса подойдет, тк на реальном задании это число должно быть известно.

 

- тесты на email ожидают "отправку формы", а тесты на имя - перенаправление на другую страницу. У нас тут разные формы?

да, тут так же ошибка:( В ожидаемом результате для Name указано, результат отправки формы с всеми заполненными полями, а в email, как вы и написали, идет ожидание отправки формы. Думаю тут нужно добавить новый тест-кейс, отправка формы с правильно заполненными полями, и как вы правильно написали:

Было бы здорово увидеть в списке проверку ситуации, например, такой: оставили оба поля пустыми -> нажали "submit" (ну или чем мы там форму отправляем -> подсветились ОБА поля.

но получается надо проверить отправку формы и с пустыми полями по отдельности(например поле Name не заполнено, остальные заполнены)? И видимо их комбинаций, те одно поле заполнено, остальные, например 3 нет, потом 2 поля заполнены, остальные 2 нет и тд, или достаточно минимальной проверки для каждого поля(текущее поле не заполнено, остальные заполнены)? Иначе количество тест-кейсов сильно увеличивается...

 

Общее впечатление: неаккуратно, как из-под палки делал

 

 - что я вижу в аттаче - есть не тест-кейсы, а чек-лист. Тоже неплохо, но давай называть вещи своими именами? ;)

это часть из моих первых тест-кейсов, поэтому пока проскакивают детские ошибки:(

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

[Murat_Minsk]

Спасибо за ответ

 

По-моему, последние три пункта - по сути одна ситуация) или имеется, что "без доменной части" - email заканчивается @, "без локальной части" - начинается @?

да, так и имелось ввиду.

 

Тестируется форма входа или форма регистрации? если форма регистрации, можно было б, например,  сделать проверку на уникальность name, email.

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

можно считать это формой отправки фидбека, на которой нет дополнительных проверок связанных с корректностью или уникальностью имени

[bu4er]

Для поля Email мог бы больше тестов придумать.

 

Например начитается и/или заканчивается цифрой. Иногда считает некорректным почту начинающуюся с цифры.

По поводу спецсимволов я вот не пойму зачем ты @ объединил вместе с остальными, его лучше отдельно проверять.
Например без знака @, с двумя знаками @@.
А с остальными спец символами у меня как то раз было так:
поле пропускало все спец символы кроме # и ^. И еслиб я спецсимволы проверил одним тестом(все в одном емаиле) я бы не заметил что другие поле пропускает.

Подумай еще какие тесты можно придумать для поля Email. Я пока подсказывать не буду 

[Dalay_LAMO]

Хочу добавить, что надо понимать абстрактность такого задания. В реальности всегда есть требования (может быть, не оформленные). И в зависимости от требований поле емейла в форме фидбека может вообще не валидироваться, может валидироваться регэскпом различной сложности, а может проверяться работоспособность указанного почтового домена.
Потестировать емейл на соответствие RFC полезно в начале карьеры для понимания, какими бывают требования, и поупражняться в тест-дизайне. В работе - сначала проясняем требования, потом тестируем.