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

Постараюсь обьяснить подробнее. В мире тестирования, требований, на самом деле выставляется не так уж и много. Чаще всего при разработке в современных рядовых компаниях все стараются избавиться от бюроктратии по максимому, К сожалению под этот нож попадают и требования. По этому при тестировании нового функционала все требования будут представлены скорее всего только мокапами (интерфейс дизайн) будущего проект. Требования не прописываются для каждого из полей, особенно если они стандартные. По этому наша тренировка в уровне 4 состоит в обучении формировать базовые требования к стандартным элементам самостоятельно. Это собственно и есть базовый опыт тестировщика - уметь самостоятельно без требований проверить стандартные функциональные элементы

1. Это очень важная тренировка на умение работать без требований с основными используемыми в работе полями. В задании необходимо самому сформировать требования на основании общих понятий о формате данных. Например емейл - https://habrahabr.ru/post/55820/ 2, Используйте шаблон. Это тоже тест кейс но параметрический, он не содержит шагов, эту информацию можно опустить, так как она очевидна

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

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

По поводу чек листа Требование номер 1 - чтобы он покрывал все баги сайта регрессивными тестами Требование номер 2 - проверки должны покрыть весь сайт, да Требование 3 - унифицировать похожие проверки Требование 4 - соблюдать модульность и иерархию сайта. Проверяем хеадер, футер, страницу 1,2 ...

Добрый день. Обратите внимание на примеры тест кейсов данных вам в уровне 3. Все примеры из реальной практики тестирования. Все хорошие примеры собраны тут. Все тест кейсы объединяются в тест план либо карту функционала (а она входит в тест план) Тест кейсы не должны быть длинными и включать много тем, наиболее оптимальны небольшие тест кейсы на 10-30 шагов. Источникам тестовых данных тест кейсы делятся на 2 типа: покрытие функционала и по документации (user story, спецификации и пр,). В первом случае вы последовательно описываете регрессионное тестирование всего функционала по модулям, а во втором покрываете тестами функционал рукводствуясь документацией. Добавлять скриншоты не нужно если без них можно разобраться в функционале, В реальной работе никто не мешает все в один тест кейс а составляет тестовые наборы и тест планы.

Use cases - варианты использования (разработанного программного обеспечения) User story - Пользовательские истории. Предполагаемый аналитиками сценарий использования ПО пользователем. Еще раз более детально о том что есть что: User story - это краткое описание того, что ваш клиент будет делать, когда он придет на сайт, или начнет использовать ваше приложение / программное обеспечение. При этом use story ориентированна на ценность или результат, получаемый от этого ПО. Они пишутся с точки зрения человека, использующего ваш сайт или приложение, и написаны на том языке, который будут использовать ваши клиенты. Use cases - описание набора взаимодействий между системой и одним или несколькими участниками (где «актером» может быть как человек так и другие системы: например, как онлайн-покупатели, так и платежная система с которой работает ваш интернет магазин могут быть участниками). Use cases обычно создаются как полноценные документы и обычно включают такую информацию: - Название - Обоснование / описание / цель - Актер / пользователь - Предварительные условия (вещи, которые, должно произойти в системе до начала действия) - Стандартный путь или основной сценарий к успеху (то что обычно происходит, описывается как последовательность шагов как в тест-кейсе) - Альтернативные пути или расширения (изменения в случаях выше / крайности) (Что будет сделано системой в финале шагов).

Александр, Test Result переводится дословно, как тестовый результат. У каждого пройдено кейса в тест-кейсе должен быть результат отображенный через статус. Если тест пройден успешно то - pass Если тест провален то - fail, а в комментариях следует указать номер или ссылку на найденный дефект Если тест пройти невозможно то - blocked

Добрый день. Как в всегда рады помочь тем кто обратился на сторону тестирования. Вот небольшой список ссылок по теме. Для iOS: Вот полное описание требований от apple - https://developer.apple.com/app-store/review/guidelines/#design Но оно на английском.  Вот еще описание самой операционки, может быть полезно - https://www.apple.com/ru/ios/ios-10/ Принципы дизайна: https://developer.apple.com/ios/human-interface-guidelines/overview/design-principles/ Для android: Андроид приложения не имеют таких строгих правил как эпл, а в основном ограниченны возможностью самой ОС. Общие правила приложений: https://play.google.com/intl/ru/about/developer-content-policy/ Статья на тему:  https://mabee.ru/publishing/sovety/pravila-app-store-pravila-google-play-chast-2/

Добрый день Cтруктура тест кейса такая: предусловия > (если нужно) шаг > ожидаемый результат > фактический результат проверки пост условия > (если нужно) Чек лист же состоит же из указаний к проверке Например проверить для всех страниц который содержат галерею (nature, foto ...) что при нажатии открывается изображение, а также его можно пролистать и закрыть В этом случае получается, что и шаги и проверки совмещены в одном выражении. Чек лист отличает от тесткейса обобщенность и компактность

Добрый день. В бекграунд разделе нужно дать основное описание фичи. Объем не большой, 1-2 абзаца достаточно. На примере pages - описываете там, что есть меню управления страницами, есть сам сайт, есть меню которое отображает страницы. Также описываете как они взаимодействуют.