Тестовые сценарии документ

Что такое тестирование сценария?

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

Давайте изучим это с помощью видео ниже —

Зачем создавать тестовые сценарии?

Тестовые сценарии создаются по следующим причинам:

• Создание тестовых сценариев обеспечивает полное покрытие тестами
• Сценарии тестирования могут быть одобрены различными заинтересованными сторонами, такими как бизнес-аналитик, разработчики, клиенты, для обеспечения тщательного тестирования тестируемого приложения. Это гарантирует, что программное обеспечение работает для наиболее распространенных случаев использования.
• Они служат быстрым инструментом для определения трудозатрат на тестирование и, соответственно, создают предложение для клиента или организуют рабочую силу.
• Они помогают определить наиболее важные сквозные транзакции или реальное использование программных приложений.
• Для изучения сквозного функционирования программы, тестовый сценарий имеет решающее значение.

Когда не создать тестовый сценарий?

Тестовые сценарии не могут быть созданы, когда

• Тестируемое приложение является сложным, нестабильным, и в проекте есть время.
• Проекты, которые следуют Agile методологии, такие как Scrum, Kanban, могут не создавать тестовые сценарии.
• Сценарий тестирования не может быть создан для исправления новой ошибки или регрессионного тестирования . В таких случаях сценарии тестирования должны быть уже задокументированы в предыдущих циклах тестирования. Это особенно верно для проектов технического обслуживания.

Как написать тестовые сценарии

Как тестер, вы можете выполнить следующие пять шагов для создания тестовых сценариев:

• Шаг 1 : Прочтите документы с требованиями, такие как BRS, SRS, FRS, тестируемой системы (SUT). Вы также можете сослаться на примеры использования, книги, руководства и т. Д. Приложения, подлежащего тестированию.
• Шаг 2 : Для каждого требования определите возможные действия и цели пользователей. Определить технические аспекты требования. Определите возможные сценарии злоупотребления системой и оцените пользователей с менталитетом хакера.
• Шаг 3: После прочтения Документа с требованиями и проведения надлежащего анализа перечислите различные сценарии тестирования, которые проверяют каждую функцию программного обеспечения.
• Шаг 4: После того, как вы перечислили все возможные сценарии тестирования, создается матрица отслеживания, чтобы убедиться, что каждому требованию соответствует соответствующий сценарий тестирования.
• Шаг 5: Созданные сценарии проверяются вашим руководителем. Позже они также рассматриваются другими заинтересованными сторонами в проекте.

Советы по созданию тестовых сценариев

• Каждый тестовый сценарий должен быть привязан как минимум к одному требованию или пользовательской истории в соответствии с методологией проекта.
• Перед созданием тестового сценария, который проверяет несколько требований одновременно, убедитесь, что у вас есть тестовый сценарий, который проверяет это требование изолированно.
• Избегайте создания слишком сложных тестовых сценариев, охватывающих несколько требований.
• Количество сценариев может быть большим, и запускать их все дорого. Исходя из приоритетов клиента, запускайте только выбранные тестовые сценарии

Пример 1. Сценарий тестирования для приложения электронной коммерции

Для приложения электронной коммерции несколько тестовых сценариев

Тестовый сценарий 1: проверка функциональности входа

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

1. Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
2. Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
3. Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
4. Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
5. Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
6. Проверить Забыли пароль работает как положено
7. Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
8. Проверять поведение системы, когда установлен флажок «Держать меня в подписи»

Как видно, тестовые случаи являются более конкретными.

Тестовый сценарий 2. Проверка функциональности поиска

Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).

ОСНОВНЫЕ ТЕРМИНЫ

Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:

1. планированием работ (Test Management)

2. проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.

3. выполнением тестирования (Test Execution)

4. анализом результатов (Test Analysis)

Основные цели тестирования

• техническая: предоставление актуальной информации о состоянии продукта на данный момент.

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

Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.

Следует уметь различать, что:

• Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).

• Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.

• Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).

Жизненный цикл бага

Атрибуты дефекта

• Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.

Градация Серьезности дефекта

• Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.

НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА

1. Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.

2. Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

3. Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.

4. Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

5. Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).

6. Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

7. Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.

8. Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить общее количество тест-кейсов. Используется для тестирования, например, фильтров, сортировок. Этот интересный метод заслуживает отдельного внимания и более подробно рассматривается в статье по ссылке (в конце которой упоминаются инструменты для автоматизации применения PT).

9. Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.

10. Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.

ВИДЫ ТЕСТИРОВАНИЯ

Классификация по целям

• Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.

Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.

Классификация по позитивности сценария

• Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.

• Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.

Классификация по знанию системы

• Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.

• Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).

• Тестирование чёрного ящика (Black Box) — метод тестирования ПО, также известный как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, которая не предполагает доступа (полного или частичного) к системе, т.е. основывается на работе исключительно с внешним интерфейсом тестируемой системы.

Классификация по исполнителям тестирования

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

• Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.

Классификация по уровню тестирования

• Модульное (компонентное) тестирование (Unit Testing) проводится самими разработчиками, т.к. предполагает полный доступ к коду, для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде, проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

• Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

Подходы к интеграционному тестированию

• Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.

• Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.

Классификация по исполнению кода

• Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки. Например, путем анализа кода (code review). Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к этому виду относится тестирование требований, спецификаций и прочей документации.

• Динамическое тестирование проводится на работающей системе, т.е. с осуществлением запуска программного кода приложения.

Классификация по хронологии выполнения

• Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.

• Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.

• Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

ДОКУМЕНТАЦИЯ

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

Основные атрибуты требований:

• Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.

• Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.

• Недвусмысленность — требование должно содержать однозначные формулировки.

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

• Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).

Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:

• Что нужно тестировать?

• Как будет проводиться тестирование?

• Когда будет проводиться тестирование?

• Критерии начала тестирования.

• Критерии окончания тестирования.

Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.

Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.

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

Тестовый сценарий (Test Case) — это документ, в котором содержатся условия, шаги и другие параметры для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

• Предусловия (PreConditions) используются, если предварительно систему нужно приводить к состоянию пригодному для проведения проверки; т.е. указываются либо действия, с помощью которых система оказывается в нужном состоянии, либо список условий, выполнение которых говорит о том, что система находится в нужном состоянии для основного теста.

• Шаги (Steps) — cписок действий, переводящих систему из одного состояния в другое, для получения результата.

• Ожидаемый результат (Expected result), на основании которого можно делать вывод о удовлетворении поставленным требованиям.

• иногда используются Постусловия (PostConditions), как некоторое напоминание для перевода системы в первоначальное состояние, как до проведения теста (initial state)

Из тестовых сценариев, сгруппированных по некоему признаку (например, тестируемой функциональности), получаются некоторые наборы. Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего для Test script), так и независимыми (Test suite).

Отчёт о дефекте (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе функциональности.

Огромное спасибо @alexlobach и @Gennadii_M за статьи! Большая часть информации взята именно оттуда.

UPD: статья пополняется. Спасибо @yakoeka

Спасибо большое всем за фидбэк, благодаря которому материал обновляется и дополняется

11.1. Тест-планы

11.1.1. Технологические цепочки и роли участников проекта, использующих тест-планы. Связь тест-планов с другими типами проектной документации.

На основании тест-требований составляются тест-планы — программы испытаний (проверки, тестирования) программной реализации системы. В отличие от тест-требований в тест-плане описываются конкретные способы проверки функциональности системы, т.е. то, как должна проверяться функциональность. Как правило, тест-план состоит из отдельных тестовых примеров, каждый из которых проверяет некоторую функцию или набор функций системы. Для каждого тестового примера однозначно определяется критерий успешного прохождения ( pass/fail criteria ), при помощи которого можно судить — соответствует ли поведение системы заданному в требованиях или нет (Рис 11.1).

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

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

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

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

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

11.1.2. Возможные формы подготовки тест-планов

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

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

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

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

11.1.3. Сценарии

Представление сценариев, удобное для ручного тестирования — тест-план в виде текстового документа, в котором каждый тестовый пример представляет один раздел. Для каждого тестового примера в этот документ записывается следующая информация:

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

Подразумевается, что действия сценария должны быть описаны таким образом, чтобы их мог воспроизвести человек практически с любым уровнем подготовки. Описание ожидаемой реакции системы должно также быть записано таким образом, чтобы можно было однозначно судить — соответствует реакция ожидаемой или нет.

Так, неудачной ожидаемой реакцией при ручном тестировании была бы запись

Сообщение "Загрузка" пропадает через приемлемое время

Степень приемлемости здесь будет зависеть от терпеливости тестировщика, и обеспечить повторяемость тестирования будет затруднительно. Более удачной формой описания той же самой ожидаемой реакции будет

Сообщение "Загрузка" исчезает с экрана не более, 
чем через 10 секунд после появления.

Ниже приведен пример описания тестового примера в виде сценария, предназначенного для ручного тестирования:

Группа тестов: Работа с учетными записями

Тестовый пример: 1289-15

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

Тест-требования: 8.5.8.1, 8.5.8.2

Предусловия для теста: Система должна быть приведена 
в состояние "Максимальная защита" и сброшена 
в настройки по умолчанию.

Критерий прохождения теста: Все ожидаемые значения 
совпадают с реальными.

Enter your credentials…
Login:

Default user blocked - system set to High security

Как можно видеть, такая форма представления действительно неудобна для автоматизации тестирования и предназначена исключительно для ручного тестирования. Иногда такие тест-планы совмещают с отчетами о проведении тестирования, добавляя в таблицу описания сценария третью и четвертые колонки — «Реальный результат» и «Соответствует», в который заносятся реальная реакция системы и указание на совпадение/несовпадение результатов соответственно. В конце описания каждого тестового примера добавляется графа «Пройден/не пройден», в которую заносится информация о том, пройден ли тестовый пример в целом. В конце всего тест-плана, совмещенного с отчетом, помещается графа «Тестовых примеров пройдено/всего», в которую заносится число пройденных тестовых примеров и общее их число.

Сценарии тестирования для автоматического тестирования часто описывают на том или ином языке программирования. Например, методы в тестирующих классах Microsoft Visual Studio Team Edition представляют собой именно пошаговые описания действий, которые необходимо выполнить тестовому окружению для проведения тестирования. Возможна и более близкая к естественному языку форма подготовки тестовых примеров. Например, при тестировании логической функции с уровнем покрытия MC/DC и описании тестовых примеров на одном из диалектов Visual Basic Script возможно записать сценарий тест-плана в такой форме:

'----------------------------------------------------------------
'                         TEST CASES                                        
'----------------------------------------------------------------
' 8 testcases
'                          1  2  3  4  5  6  7  8
' -----------------------------------------------
' computed                 -  -  0  0  0  -  -  -
' good1                    0  1  0  0  0  0  0  0
' computed2                -  -  -  -  0  -  -  -
' good2                    1  1  1  0  0  1  1  1
' delay                    -  -  -  -  -  0  -  -
' pack1                    1  1  1  1  1  1  0  0
' pack2                    0  0  0  0  0  0  0  1
' -----------------------------------------------
' output_message           1  0  0  1  0  0  0  1


'-------------------------------------------------------------------
' Testcase #1:
Call Test_Message_Call (-, 0, -, 1, -, 1, 0, 1)
'-------------------------------------------------------------------
' Testcase #2:
Call Test_Message_Call (-, 1, -, 1, -, 1, 0, 0)
'-------------------------------------------------------------------
' Testcase #2:
Call Test_Message_Call (0, 0, -, 1, -, 1, 0, 0)
'-------------------------------------------------------------------' Testcase #4:
Call Test_Message_Call (0, 0, -, 0, -, 1, 0, 1)
'-------------------------------------------------------------------' Testcase #5:
Call Test_Message_Call (0, 0, 0, 0, -, 1, 0, 0)
'-------------------------------------------------------------------' Testcase #6:
Call Test_Message_Call (-, 0, -, 1, 0, 1, 0, 0)
'-------------------------------------------------------------------' Testcase #7:
Call Test_Message_Call (-, 0, -, 1, -, 0, 0, 0)
'-------------------------------------------------------------------' Testcase #8:
Call Test_Message_Call (-, 0, -, 1, -, 0, 1, 1)

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

Введение в тестовый сценарий

Тестовый сценарий — это комбинация двух слов, то есть теста и сценария. Тест представляет собой акт проверки или подтверждения, а сценарий представляет собой путешествие пользователя. Любая тестируемая функциональность называется сценарием тестирования. Сценарий тестирования может быть описан как проверка или подтверждение правильности поездки пользователя. Он будет в форме документов, содержащих все тестовые примеры, подробно написанные для проверки сквозной функциональности приложений. Это одна из высокоуровневых категорий требований, которые можно проверить. Это также известно как возможность тестирования или условия тестирования.

Зачем создавать тестовые сценарии?

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

Причина их создания заключается в следующем:

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

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

• Его нельзя создавать в проектах, следующих за гибкими методологиями, такими как Scrum и т. Д.
• Когда тестируемые приложения нестабильны или слишком сложны, или когда проект находится в критическом состоянии, его создания можно избежать.
• Его можно избежать для регрессионного тестирования или для новой ошибки, потому что в проектах технического обслуживания их тяжелая документация может произойти заранее в предыдущих циклах тестирования.

Как тестовые сценарии могут быть написаны?

Следующие шаги могут быть выполнены тестером для создания тестовых сценариев:

• Шаг 1: Документ о требованиях, таких как Спецификация бизнес-требований (BRS), Спецификация функциональных требований (FRS) и Спецификация системных требований (SRS) приложения, подлежащего тестированию, следует внимательно и тщательно прочитать. Руководства, книги, варианты использования и т. Д. Тестируемого приложения могут быть отнесены к тому же.
• Шаг 2: Все возможные цели и действия пользователя должны быть правильно определены для каждого требования. Все технические характеристики каждого требования также должны быть определены.
• Шаг 3: Все возможные причины взлома системы и оценки пользователя должны выполняться с точки зрения хакера. Оценка пользователя может быть выполнена путем нахождения всех возможностей пользовательского управления приложениями.
• Шаг 4: Полный список всех возможных тестовых случаев для проверки всех функциональных возможностей приложения должен быть составлен после полного прочтения документа с требованиями и завершения анализа.
• Шаг 5: После привлечения всех из них для проверки соответствия требования и его сценария тестирования должна быть создана матрица отслеживания.
• Шаг 6: Все созданные тестовые сценарии проверяются и оцениваются супервизором. Это также дополнительно проверяется всеми заинтересованными сторонами.

В соответствии с процедурой проекта каждый сценарий тестирования должен соответствовать как минимум одной пользовательской истории или требованию. Обязательно проверять каждый тестовый сценарий на соответствие его требованию отдельно, перед несколькими требованиями в одном тестовом сценарии. Сложные тестовые сценарии с несколькими требованиями можно избежать для простоты. Цена прямо пропорциональна их количеству. Поэтому желательно всегда запускать только выбранные и требуемые в соответствии с приоритетом клиента.

Примеры

Ниже приведены несколько примеров сценария тестирования.

Тестовый сценарий для интернет-магазина приложений Buykart

Сценарии тестирования, которые можно принять во внимание при проверке приложения для онлайн-покупок Buykart, следующие:

Тестовый сценарий 1: проверка работоспособности входа

Тестовые случаи, которые можно рассмотреть для создания:

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

Тестовый сценарий 2. Проверка функциональности поиска

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при поиске действующего товара.
• Поведение приложения при поиске недействительного продукта.

Тестовый сценарий 3: проверка деталей продукта

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при выборе продукта.
• Поведение приложения продукта в списке пожеланий.
• Поведение приложения при добавлении товара в корзину.
• Поведение приложения при выборе опции «Купить сейчас».
• Поведение приложения при вводе неверного адреса.
• Поведение приложения при вводе действительного адреса.
• Поведение приложения при проверке нескольких вариантов оплаты.

Тестовый сценарий 4: проверка функциональности платежа

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при выборе каждого варианта оплаты.
• Поведение приложения, когда выбран правильный способ оплаты.
• Поведение приложения при выборе неверного варианта оплаты.
• Поведение приложения при успешной оплате.
• Поведение приложения при отклонении платежа.

Тестовый сценарий 5: проверка функциональности деталей заказа

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при выборе каждого заказа.
• Поведение приложения при выборе опции «Возврат товара».
• Поведение приложения при выборе опции отслеживания товара.
• Поведение приложения при выборе опции «Обзор продукта».

Вывод

Он служит надлежащим руководством для тестировщиков и помогает им сделать тестирование более эффективным и действенным. Это помогает уменьшить сложность тестирования и избыточность. Каждый тестовый пример написан подробно для лучшего понимания. Это очень экономит время для тестеров.

Рекомендуемые статьи

Это было руководство к тому, что такое тестовый сценарий. Здесь мы обсудим, как создавать тестовые сценарии на разных примерах. Вы также можете взглянуть на следующие статьи, чтобы узнать больше —

1. Стресс нестабильности работы
2. Мотивированный и посвященный
3. Что такое Agile Testing?
4. Как написать контрольный пример?

Тестовый случай (Test Case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Высокоуровневый тест-кейс — тест-кейс без конкретных входных данных и ожидаемых результатов. Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне дымового тестирования. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов.

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

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

Спецификация теста — документ, состоящий из спецификации тест-дизайна, спецификации тест-кейса (test case specification) и/или спецификации тест-процедуры (test procedure specification).

Тест-сценарий (test scenario, test procedure specification, test script) — документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»).

Цель написания тест-кейсов:

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

1. Структурировать и систематизировать подход к тестированию (без чего крупный проект почти гарантированно обречён на провал).
2. Вычислять метрики тестового покрытия (test coverage metrics) и принимать меры по его увеличению (тест-кейсы здесь являются главным источником информации, без которого существование подобных метрик теряет смысл).
3. Отслеживать соответствие текущей ситуации плану (сколько примерно понадобится тест-кейсов, сколько уже есть, сколько выполнено из запланированного на данном этапе количества и т.д.).
4. Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками (тест-кейсы зачастую намного более наглядно показывают поведение приложения, чем это отражено в требованиях)..
5. Хранить информацию для длительного использования и обмена опытом между сотрудниками и командами (или, как минимум, не пытаться удержать в голове сотни страниц текста).
6. Проводить регрессионное тестирование и повторное тестирование (которые без тест-кейсов было бы вообще невозможно выполнить).
7. Повышать качество требований (написание чек-листов и тест-кейсов — хорошая техника тестирования требований).
8. Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту.

Жизненный цикл тест-кейса

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

Создан (new) — типичное начальное состояние практически любого артефакта. Тест-кейс автоматически переходит в это состояние после создания.

Запланирован (planned, ready for testing) — в этом состоянии тест-кейс находится, когда он или явно включён в план ближайшей итерации тестирования, или, как минимум, готов для выполнения.

Не выполнен (not tested) — в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.

Выполняется (work in progress) — если тест-кейс требует длительное время для выполнения, то он может быть переведён в это состояние для подчёркивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние, как правило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний — «провален», «пройден успешно» или «заблокирован».

Пропущен (skipped) — бывают ситуации, когда выполнение тест-кейса отменяется по соображениям нехватки времени или изменения логики тестирования.

Провален (failed) — данное состояние означает, что в процессе выполнения тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый результат по как минимум одному шагу тест-кейса не совпадает с фактическим результатом. Если в процессе выполнения тест-кейса был «случайно» обнаружен дефект, никак не связанный с шагами тест-кейса и их ожидаемыми результатами, тест-кейс считается пройденным успешно (при этом, естественно, по обнаруженному дефекту создаётся отчёт о дефекте).

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

Заблокирован (blocked) — данное состояние означает, что по какой-то причине выполнение тест-кейса невозможно (как правило, такой причиной является наличие дефекта, не позволяющего реализовать некий пользовательский сценарий).

Закрыт (closed) — очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В некоторых системах управления тест-кейс переводят в данное состояние, чтобы подчеркнуть тот факт, что на данной итерации тестирования все действия с ним завершены.

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

Структура тест кейса

Идентификатор (identifier) представляет собой уникальное значение, позволяющее однозначно отличить один тест-кейс от другого и используемое во всевозможных ссылках. В общем случае идентификатор тест-кейса может представлять собой просто уникальный номер, но (если позволяет инструментальное средство управления тест-кейсами) может быть и куда сложнее: включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить цель тест-кейса и часть приложения (или требований), к которой он относится (например, UR216_S12_DB_Neg).

Приоритет (priority) показывает важность тест-кейса. Он может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но, чаще всего, лежит в диапазоне от трёх до пяти.

Приоритет тест-кейса может коррелировать с:

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

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

Связанное с тест-кейсом требование (requirement) показывает то основное требование, проверке выполнения которого посвящён тест-кейс (основное, поскольку один тест-кейс может затрагивать несколько требований). Наличие этого поля улучшает такое свойство тест-кейса, как прослеживаемость. Заполнение этого поля является не обязательным.

Модуль и подмодуль приложения (module and submodule) указывают на части приложения, к которым относится тест-кейс, и позволяют лучше понять его цель. Идея деления приложения на модули и подмодули проистекает из того, что в сложных системах практически невозможно охватить взглядом весь проект целиком, и вопрос «как протестировать это приложение» становится недопустимо сложным. Тогда приложение логически разделяется на компоненты (модули), а те, в свою очередь, на более мелкие компоненты (подмодули). Как правило, иерархия модулей и подмодулей создаётся как единый набор для всей проектной команды, чтобы исключить путаницу из-за того, что разные люди будут использовать разные подходы к такому разделению или даже просто разные названия одних и тех же частей приложения. В реальности проще всего отталкиваться от архитектуры и дизайна приложения. Например, в уже знакомом нам приложении можно выделить такую иерархию модулей и подмодулей:

• Механизм запуска:
  • механизм анализа параметров;
  • механизм сборки приложения;
  • механизм обработки ошибочных ситуаций.
• Механизм взаимодействия с файловой системой:
  • механизм обхода дерева SOURCE_DIR;
  • механизм обработки ошибочных ситуаций.

Заглавие (суть) тест-кейса (title) призвано упростить и ускорить понимание основной идеи (цели) тест-кейса без обращения к его остальным атрибутам.

Исходные данные, необходимые для выполнения тест-кейса (precondition, preparation, initial data, setup), позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-кейса, например:

• состояние базы данных;
• состояние файловой системы и её объектов;
• состояние серверов и сетевой инфраструктуры.

Шаги тест-кейса (steps) описывают последовательность действий, которые необходимо реализовать в процессе выполнения тест-кейса.

Общие рекомендации по написанию шагов таковы:

1. Начинайте с понятного и очевидного места, не пишите лишних начальных шагов (запуск приложения, очевидные операции с интерфейсом и т.п.).
2. Даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает вероятность в будущем случайно «приклеить» описание этого шага к новому тексту).
3. Если вы пишете на русском языке, то используйте безличную форму (например, «открыть», «ввести», «добавить» вместо «откройте», «введите», «добавьте»), в английском языке не надо использовать частицу «to» (т.е. «запустить приложение» будет «start application», не «to start application»).
4. Соотносите степень детализации шагов и их параметров с целью тест-кейса, его сложностью, уровнем и т.д. В зависимости от этих и многих других факторов степень детализации может варьироваться от общих идей до предельно чётко прописанных значений и указаний.
5. Ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста (например, «повторить шаги 3–5 со значением…»).
6. Пишите шаги последовательно, без условных конструкций вида «если… то…».

Ожидаемые результаты (expected results) по каждому шагу тест-кейса описывают реакцию приложения на действия, описанные в поле «шаги тест-кейса». Номер шага соответствует номеру результата.

По написанию ожидаемых результатов можно порекомендовать следующее:

• Описывайте поведение системы так, чтобы исключить субъективное толкование (например, «приложение работает верно» — плохо, «появляется окно с надписью…» — хорошо).
• Пишите ожидаемый результат по всем шагам без исключения, если у вас есть хоть малейшие сомнения в том, что результат некоего шага будет совершенно тривиальным и очевидным (если вы всё же пропускаете ожидаемый результат для какого-то тривиального действия, лучше оставить в списке ожидаемых результатов пустую строку — это облегчает восприятие).
• Пишите кратко, но не в ущерб информативности.
• Избегайте условных конструкций вида «если… то…».

Набор тест-кейсов (test case suite, test suite, test set) — совокупность тест-кейсов, выбранных с некоторой общей целью или по некоторому общему признаку.

Наборы тест-кейсов можно разделить на свободные (порядок выполнения тест-кейсов не важен) и последовательные (порядок выполнения тест-кейсов важен).

Преимущества свободных наборов:

• Тест-кейсы можно выполнять в любом удобном порядке, а также создавать «наборы внутри наборов».
• Если какой-то тест-кейс завершился ошибкой, это не повлияет на возможность выполнения других тест-кейсов.

Преимущества последовательных наборов:

• Каждый следующий в наборе тест-кейс, в качестве входного состояния приложения, получает результат работы предыдущего тест-кейса, что позволяет сильно сократить количество шагов в отдельных тест-кейсах.
• Длинные последовательности действий куда лучше имитируют работу реальных пользователей, чем отдельные «точечные» воздействия на приложение.

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

Классификация наборов тест-кейсов

• Набор изолированных свободных тест-кейсов: действия из раздела «приготовления» нужно повторять перед каждым тест-кейсом, а сами тест-кейсы можно выполнять в любом порядке.
• Набор обобщённых свободных тест-кейсов: действия из раздела «приготовления» нужно выполнить один раз (а потом просто выполнять тест-кейсы), а сами тест-кейсы можно выполнять в любом порядке.
• Набор изолированных последовательных тест-кейсов: действия из раздела «приготовления» нужно повторять перед каждым тест-кейсом, а сами тест-кейсы нужно выполнять в строго определённом порядке.
• Набор обобщённых последовательных тест-кейсов: действия из раздела «приготовления» нужно выполнить один раз (а потом просто выполнять тест-кейсы), а сами тест-кейсы нужно выполнять в строго определённом порядке.

Главное преимущество изолированности: каждый тест-кейс выполняется в «чистой среде», на него не влияют результаты работы предыдущих тест-кейсов.

Главное преимущество обобщённости: приготовления не нужно повторять (экономия времени).

Главное преимущество последовательности: ощутимое сокращение шагов в каждом тест-кейсе, т.к. результат выполнения предыдущего тест-кейса является начальной ситуацией для следующего.

Главное преимущество свободы: возможность выполнять тест-кейсы в любом порядке, а также то, что при провале какого-то тест-кейса (приложение не пришло в ожидаемое состояние) остальные тест-кейсы по-прежнему можно выполнять.

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

Подходы к составлению наборов тест-кейсов:

• На основе чек-листов.
• На основе разбиения приложения на модули и подмодули. Для каждого модуля (или его отдельных подмодулей) можно составить свой набор тест кейсов.
• По принципу проверки самых важных, менее важных и всех остальных функций приложения.
• По принципу группировки тест-кейсов для проверки некоего уровня требований или типа требований, группы требований или отдельного требования.
• По принципу частоты обнаружения тест-кейсами дефектов в приложении (например, мы видим, что некоторые тест-кейсы раз за разом завершаются неудачей, значит, мы можем объединить их в набор, условно названный «проблемные места в приложении»).
• По архитектурному принципу: наборы для проверки пользовательского интерфейса и всего уровня представления, для проверки уровня бизнес-логики, для проверки уровня данных.
• По области внутренней работы приложения, например, «тест-кейсы, затрагивающие работу с базой данных», «тест-кейсы, затрагивающие работу с файловой системой», «тест-кейсы, затрагивающие работу с сетью».
• По видам тестирования.

• Что такое тестовая документация
• В чем ее важность
• Какую тестовую документацию используют QA-команды
• Тест-план
• Чеклист
• Тест-кейс
• Сценарий использования
• Баг-репорт
• Требования
• Как все это работает

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

Что такое тестовая документация?

Тестовая документация — это набор документов, создаваемых перед началом процесса тестирования и непосредственно в процессе. Эти документы описывают покрытие тестами и процесс выполнения тестов, в них указываются необходимые для тестирования вещи, приводится основная терминология и т. д. 

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

В чем важность тестовой документации?

Если тестирование не документируется, это мешает увидеть полную картину проекта. Без четких целей, пошагового плана по их достижению и указания всех важных условий ожидаемый результат будет неясен. В таких условиях у всех может быть разное понимание общей цели и конечного продукта.

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

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

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

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

Отсутствие документации может серьезно повлиять на работу тестировщиков. Это особенно верно при работе со сложными продуктами или при часто меняющихся требованиях.

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

Какую тестовую документацию используют QA-команды?

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

План тестирования (test plan)

План тестирования описывает все действия по тестированию в рамках одного проекта. Здесь вы можете найти информацию обо всем, что нужно сделать тестировщику или команде QA в ходе проекта. 

В каждом плане тестирования указывается объект тестирования, график работы, критерии начала и окончания тестирования, стратегия, риски и список выполненных работ.

Чеклист (checklist)

Чеклист — это документ, содержащий краткое описание функций, которые должен проверить тестировщик. 

Выглядит чеклист как список функций с указанием статуса — результата проверки. 

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

Тест-кейс (test case)

В тест-кейсе содержатся:

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

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

Сценарий использования (use case)

Use case — это более простой и менее официальный документ. Он описывает сценарий взаимодействия с программным обеспечением. 

Каждый юзкейс основан на предположении о том, что пользователь программы будет делать и где он будет кликать. Это позволяет тестировщикам протестировать предполагаемые пути пользователя. 

При создании юзкейсов тестировщики учитывают требования и бизнес-цели.

Баг-репорт

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

Подробный и эффективный баг-репорт значительно увеличивает шансы быстро исправить баг.

Требования (requirements specification)

Спецификация требований или просто требования — это полное описание разрабатываемого программного обеспечения. 

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

Как все это работает?

Документы бывают высоко- и низкоуровневые. Все тестировщики могут составлять чеклисты, тест-кейсы и баг-репорты. Это часть их повседневных обязанностей. 

А вот подготовка плана тестирования требует дополнительных навыков и опыта. Это задача для опытного специалиста или QA Lead.

Чем крупнее проект, тем больше документации нужно. 

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

Тестовая документация динамична. Она эффективна только в том случае, если команда QA регулярно ее обновляет. 

Если документацию заводят только «чтобы было», никакого смысла в ней нет. В ходе тестирования могут меняться требования и приоритеты. Это влияет на покрытие тестами, необходимые ресурсы и т. д. Если команда не записывает изменения, в результате получаются неэффективные документы и непоследовательность в работе.

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

В заключение

Каждая компания сама определяет, стоит ли создавать тестовую документацию. QA-специалисты могут рекомендовать клиентам это сделать, но последнее слово остается за клиентами.

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