Если вы не используете какой-либо инструмент управления тест-кейсами, то я бы настоятельно рекомендовал попробовать. Начните с какого-нибудь инструмента с открытым исходным кодом. В проектных задачах по тестированию редко кто так составляет детально тест-кейсы API в TMS, потому что мало времени на подробное описание тест-кейсов и на их актуализацию. Сперва необходимо составлять позитивные тесты – успешное прохождение сценария, затем негативные тесты с невалидными и/или недопустимыми данными, null для обязательных ключей и т.д.. Хочу вам рассказать о важности написания тест-кейсов по API, а именно про стратегию составления тест-кейсов по бэку, где результатом является хорошо структурированный тест-кейс. Как два года я введу блог по тестированию, помогаю начинающим специалистам по тестированию развивать свои хард скиллы, сочиняю тесты для закрепления знаний по основам тестирования и не только.
Можно определить так же номер типа тестов, которые буду запущены. Ниже приведен пример реального проекта, который демонстрирует, как реализуются все перечисленные советы и приемы. Кроме того, если у вас есть процедура рассмотрения тест-кейсов бизнес-командой, то эти тест-кейсы нужно оформлять по шаблону, согласованному обеими сторонами. Большинство из них предпочитают электронные таблицы Excel, потому что с их помощью можно легко группировать тест-кейсы по типам тестов и, самое главное, можно легко получить метрики тестов благодаря формулам Excel. Но я уверен, что по мере увеличения объема ваших тестов вам будет крайне сложно управлять ими.
Классификация тестирования
Описание Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке. Severity vs Priority Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения. Приоритет (Priority) — это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ.
То есть тестировщик будет выполнять все проверки, которые есть на странице, не переходя к другим проверкам. Да и искать определенный тест-кейс в этом случае более логично. Свой путь в Утконосе я начинала с мануального тестирования, поэтому в этой статье хочу поделиться с вами подходом, который я применила для создания удобной структуры и информативного содержания тестовой документации. Для проведения кейс-тестинга можно использовать уже готовые примеры, разработанные по материалам отечественного рынка.
Тест-кейс и тестовый сценарий
PostConditions в данном примере
не были описаны, но по логике вещей надо
выполнить шаги, которые бы вернули
систему в первоначальное состояние. (например, удалили созданную запись,
или отменили бы изменения сделанные в
документе). Тест-кейс должен обязательно содержать хотя бы ожидаемый результат (даже без описания действий, которые к нему ведут). Кроме ожидаемого результата необходимо пошаговое описание действий, которые позволят прийти к фактическому результату и сравнить его с ожидаемым. Краткое описание тест-кейса имеет смысл вынести в заголовок.
Требования, для которых пишется данный тест-кейс. Желательно указать точный номер раздела в документе с требованиями. У каждого тест-кейса должен быть уникальный ID. В этом идентификаторе может быть зашифрован тип тестов (в соответствии с соглашениями). Например, “TC_UI_1” означает “Тест пользовательского интерфейса № 1”. Применение специальных инструментов существенно облегчит и поможет унифицировать составление планов тестирования и написание тест-кейсов. Давайте познакомимся с несколькими такими инструментами.
Другие приемы в тестировании
Сюда можно записать и предварительные шаги, что не относится к самому тесту. На них можно ссылаться и из других тестов, но сам тест-кейс должен быть независим. В позитивных тест-кейсах используются корректные входные данные и сценарии ожидаемой работы системы. Цель здесь – убедиться, что программный продукт выполняет то, что должен делать, и что система не выдаст ошибку, если это не предусмотрено. Тестировать требования необходимо на самых ранних этапах и/или стадиях процесса разработки (думаю, что Америки я не открыл). TestRail является программным обеспечением для управления данными полученными в результате тестирования.
- Если требование имеет дочерние требования, то для каждого такого дочернего требования должен быть создан/выполнен также по крайней мере один тест-кейс.
- Подтверждают, что ПО соответствует требованиям.
- Но я уверен, что по мере увеличения объема ваших тестов вам будет крайне сложно управлять ими.
- Исходя из такого подхода к качественному продукту, можно дать следующее определение тестированию.
- Решение проблемы необходимо для дальнейшего функционирования системы.
На протяжении трех лет я работал на должности QA и считаю, что в IT-индустрии тестировщик, будучи частью scrum-команд, так же ценен, как и любой другой член команды. Исследовав запросы пользователей нашего сайта, мы решили опубликовать самые восстребованныыедокументы по тестированию на одной страинце. В примере 1 и 2 покрытие будет одинаковым, но вот время, которое потребуется для прохождения, будет разным.
Тест-дизайн
Отчет о тестировании пишется, когда функционал уж проверен и релиз либо предрелиз показывает итог проделанной работы. Скриншоты из разных систем, в которых баг-репорт можно вести. В разных компаниях в разных командах условия могут быть абсолютно разные, и где хранятся баг репорты — также зависит от компании. Чек-листы лучше сразу писать по требованиям (геймдизайнерскому документу) перед стартом тестирования функционала или по итогу.
Чем выше приоритет, тем быстрее нужно исправить дефект. Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
Чего не должно быть в тест-кейсе?
Во многих компаниях эта роль не выделяется отдельно, а доверяется обычным тестировщикам , что в случае недостаточной квалификации может привести к переписке тест кейсов. Одним из определений качественного продукта (не обязательного программного) является то, на сколько данный продукт удовлетворяет предъявляемым к нему требованиям. Исходя из такого подхода к качественному продукту, можно дать следующее определение тестированию. Тестирование — это процесс проверки негативный тест кейс пример соответствия продукта предъявляемым к нему требованиям. В процессе тестирования программного продукта мы определяем соответствует ли то, что написали программисты, тому, что написали консультанты и аналитики (формализовав требования и пожелания Заказчика). Тест-кейс (тестовый случай, test case) — это набор условий и/или переменных, с помощью которых тестировщик будет определять насколько полно тестируемое приложение удовлетворяет предъявляемому к нему требованию.
Подтверждают, что ПО соответствует требованиям. Показывают, что при корректных входных данных и действиях пользователя ПО выполняет функции. Абстрактное название тест кейсаТест кейсы на одном проекте часто похожи друг на друга. Чтобы в них не было путаницы, названия должны быть конкретными и однозначными. Давайте попробуем создать наш собственный тест-кейс для ручного тестирования функции поиска на e-commerce сайте компании FootWear.