Чек-лист — это https://deveducation.com/ упрощенный список того, что нужно проверить. Если при его выполнении выявлен баг, то его как раз описывают в отчете о дефекте.
Тестирование ПО: шаблоны тест-кейсов + примеры
Выполнить проверки из раздела «Операция добавления записи (Insert) — Сохранение граничных значений» на одной и той же записи в режиме редактирования. Допустимые РеГиСтР, раскладка, языки, цифры, спецсимволы, маска ввода в соответствии с требованиями и оракулами в тестировании. Составление чек-листа – это творческий процесс, который требует от вас внимательности, аккуратности и профессионализма. Чем более структурированным и подробным будет ваш чек-лист, тем более эффективнее и быстрее будет проходить тестирование. expected result Мы рассмотрели основные способы формулирования проверок в чек-листе.
- Тест-кейс (Test case) — пошаговое описание действий, которые нужно произвести для проверки какой-либо функции ПО.
- Приоритет (Priority)Высокий, так как функциональность важная.
- Но как быть уверенными, что мы не упустим ничего важного?
- Поэтому нет необходимости каждый раз заглядывать в документацию с требованиями к ПО.
- Здесь же можно дать ссылку на требования (документ, задачу в системе управления проектами, макет и т.д.) и указать текущий статус готовности.
Описание ожидаемого результата проверок
Шаги (steps) — точная последовательность действий для выполнения проверки. Название/модуль/версия продукта (Component/Version) — описание ПО, на котором можно выполнить тест-кейс. Наборы тест-кейсов можно разделить на свободные (порядок выполнения frontend разработчик тест-кейсов не важен) и последовательные (порядок выполнения тест-кейсов важен).
Пример 3: Проверка добавления товара в корзину
Чаще всего, в ЧЛ содержатся только действия, без ожидаемого результата. Test case (тест-кейс, тестовый пример/случай) – это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или ее части. Более строго – формализованное описание одной показательной проверки на соответствие требованиям прямым или косвенным. Представьте, что вы тестируете новое программное обеспечение.
Их задача — систематизировать и упростить процесс тестирования, сделать его более прозрачным и структурированным. А еще их использование может очень сильно экономить время. Отчёт о дефекте (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе функциональности. Выполняется (work in progress) – если тест-кейс требует длительное время для выполнения, то он может быть переведён в это состояние для подчёркивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние, как правило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний – «провален», «пройден успешно» или «заблокирован».
Тест-кейс имеет определенный шаблон, разработанный для того, чтобы стандартизировать и упростить создание и дальнейшее чтение тест-кейсов. Шаблон условно стандартизированный, потому что может меняться в зависимости от компаний и процессов. Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения. Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату. Создаём папку “Тест регистрации” в которой будут храниться все тест-кейсы на проверку регистрации.
Ожидаемый результат (expected result) — что мы получаем после выполнения шагов. Ссылка на требования — ссылка на требование или ТЗ, на основе которого был составлен тест-кейс. Краткое описание тест-кейса (Name).Название тест-кейса должно быть коротким и понятным. Набор тест-кейсов всегда создаётся с какой-то целью, на основе какой-то логики, и по этим же принципам в набор включаются тесты, обладающие подходящими свойствами. Не выполнен (not tested) – в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»).
Тест-сценарий (test scenario, test procedure specification, test script) – документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»). Тестовый случай (Test Case) – это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. С помощью тест-кейсов QA-инженеры определяют для коллег, как и что протестировать оптимальным образом.
Если отзыв не отображается – это значит, что не работает ключевая логика разрабатываемой фичи. На тестирование передан неработающая функциональность и проводить дальнейшее тестирование по ней нет смысла. Для каждой группы опционально можно указать общие предусловие или тестовые данные. Или просто добавить более подробное описание назначения группы проверок. Примером тест-менеджмент системы с поддержкой чек-листов является “Ситечко”.
Следовательно, если с чек-листом работают уже опытные тестировщики, то особых проблем не возникает. Если приходят новички и видят чек-листы, то они могут запутаться и неправильно проверить функциональность, потому что не будут с точностью знать, как правильно протестировать и какие данные вводить. Если будет много проверок на один компонент, то тест-кейсы можно объединить в тестовый набор или по-другому Test Suite.
В нем указывают шаги выполнения проверки и важные нюансы в них. Поэтому нет необходимости каждый раз заглядывать в документацию с требованиями к ПО. Как видим, создание эффективного чек-листа тестирования — это процесс структурирования и организации проверок, установки приоритетов и определения критериев оценки. Это помогает нам быть более систематичными и уверенными в нашей работе. При тестировании типовой функциональности, выбрать ее из списка и выполнить типовые проверки. В заключение, составление чек-листов – это важный инструмент для эффективного тестирования продуктов.
Мне кажется это уже игра словами, как назвать поле “Ожидаемый результат” при описании дефекта. Ниже приводятся общие рекомендации по описанию ожидаемого результата для всех типов проверок. В качестве примера возьмем отображение в отзыве аватара пользователя. Будет ли проверена ситуация, когда аватар не установлен у пользователя ? Также необязательно в каждой проверке писать само слово “Проверить” – оно избыточно.
Связанное с тест-кейсом требование (requirement) показывает то основное требование, проверке выполнения которого посвящён тест-кейс (основное, поскольку один тест-кейс может затрагивать несколько требований). Наличие этого поля улучшает такое свойство тест-кейса, как прослеживаемость. Тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен».
Набор тест-кейсов (test case suite, test suite, test set) – совокупность тест-кейсов, выбранных с некоторой общей целью или по некоторому общему признаку. Запланирован (planned, ready for testing) – в этом состоянии тест-кейс находится, когда он или явно включён в план ближайшей итерации тестирования, или, как минимум, готов для выполнения. Низкоуровневый тест-кейс – тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой полностью готовый к выполнению тест-кейс и является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, поскольку прописать все данные подробно намного проще, чем понять, какой информацией можно пренебречь, при этом не снизив ценность тест-кейса.
Граничные значения корректных данных в соответствии с требованиями и оракулами в тестировании. Поискать в интернете, какой MIN и MAX значения может быть — самая длинная/короткая фамилия, название города, название юр. Составление чек-листов – это процесс, который может значительно упростить и ускорить тестирование программного обеспечения.
В этой статье я хочу дать несколько практических рекомендаций по формулированию проверок в чек-листах. При внедрении в работу данной документации не придется каждый раз заново придумывать проверки и бояться что-то упустить. Достаточно один раз уделить немного больше времени на проверку и написать по ней тест-кейсы и чек-листы, чтобы потом экономить время при следующих проверках. Как видите, чек-листы и тест-кейсы сильно упрощают процесс тестирования. Отличие между ними в том, что чек-листы показывают направление тестирования, а тест-кейсы подробно описывают как тестировать. Чек-лист – это список, содержащий ряд необходимых проверок во время тестирования программного продукта.
Если нет требований и приложение еще не используется боевыми пользователями погуглить статистику популярных девайсов и браузеров (с учетом территории будущих пользователей). Если нет требований и приложение уже используется боевыми пользователями, запросить гугл/яндекс метрики. Выяснить, есть ли требования к количеству символов в поисковой строке для включения поиска, для отключения поиска. Граничные значения корректных данных в соответствии с требованиями.