В этой статье мы разберем шаблон стандартного тест-кейса, расскажем о парочке инструментов для управления тест-кейсами и приведем пример тест-кейса для ручного тестирования.
Содержание
Вступление
Каждый день мне поступает несколько запросов от желающих получить шаблон тест-кейса. Меня удивляет, что многие тестировщики все еще документируют тест-кейсы с помощью Word или Excel.
Большинство из них предпочитают электронные таблицы Excel, потому что с их помощью можно легко группировать тест-кейсы по типам тестов и, самое главное, можно легко получить метрики тестов благодаря формулам Excel. Но я уверен, что по мере увеличения объема ваших тестов вам будет крайне сложно управлять ими.
Если вы не используете какой-либо инструмент управления тест-кейсами, то я бы настоятельно рекомендовал попробовать. Начните с какого-нибудь инструмента с открытым исходным кодом.
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
Рекомендуемые инструменты
Форматы тест-кейсов могут отличаться в разных организациях. Однако использование стандартного формата для написания тест-кейсов – это еще один шаг к созданию процесса тестирования для вашего проекта.
Это также минимизирует специальное тестирование, которое проводится без надлежащего документирования тест-кейсов. Но даже если вы используете стандартные шаблоны, вам необходимо настроить процесс написания, проверки и утверждения, выполнения тестов и, самое главное, подготовки тестовых отчетов и т.д. с помощью ручных методов.
Кроме того, если у вас есть процедура рассмотрения тест-кейсов бизнес-командой, то эти тест-кейсы нужно оформлять по шаблону, согласованному обеими сторонами.
Применение специальных инструментов существенно облегчит и поможет унифицировать составление планов тестирования и написание тест-кейсов. Давайте познакомимся с несколькими такими инструментами.
TestRail
TestRail – это веб-инструмент для управления тест-кейсами и тестами. Он помогает командам тестировщиков и разработчиков эффективно управлять тест-кейсами, планами и прогонами. Он обеспечивает централизованное управление тестами, отчеты и метрики, а также повышение производительности. Это масштабируемое и настраиваемое решение. Его могут использовать команды любого размера.
Особенности:
- Упрощает отслеживание результатов тестирования.
- Легко интегрируется с баг-трекерами, автоматизированными тестами и т.д.
- Персонализированные списки задач, фильтры и уведомления по электронной почте помогут повысить производительность.
- Приборные панели и отчеты о деятельности позволяют легко следить за состоянием отдельных тестов и проектов.
Katalon Platform
Katalon Platform – это универсальный и простой инструмент автоматизации, которому доверяют более 850 000 пользователей. Он упрощает автоматизацию для тех, кто не имеет опыта программирования, позволяя создавать автоматизированные тест-кейсы из шагов ручных тестов. Имеет богатую библиотеку шаблонов проектов, функцию записи и воспроизведения, а также дружественный пользовательский интерфейс.
Testiny
Testiny – новый, простой инструмент управления тестированием. Это быстро развивающееся веб-приложение, построенное на новейших технологиях и призванное сделать ручное тестирование и управление QA максимально простым. Оно разработано так, чтобы быть чрезвычайно простым в использовании. Testiny помогает тестировщикам выполнять тесты, не добавляя громоздких накладных расходов в процесс тестирования.
Этот инструмент идеально подходит для небольших и средних команд QA, которые хотят интегрировать ручное и автоматизированное тестирование в процесс разработки.
Особенности:
- Бесплатно для проектов с открытым исходным кодом и небольших команд до 3 человек.
- Интуитивно понятный, можно использовать из коробки.
- Легко создавать и обрабатывать тест-кейсы, прогоны тестов и т.д.
- Мощные интеграции (например, с Jira)
- Бесшовная интеграция в процесс разработки (связывание требований и дефектов).
- Мгновенные обновления – все сессии браузера остаются синхронизированными.
- Членам команды видно, внес ли коллега изменения, завершил ли тест и т.д.
- Мощный REST API.
- Тесты можно организовать в интуитивно понятной и простой древовидной структуре.
Шаблон тест-кейса и его стандартные поля
Простые шаблоны могут немного упростить процесс ручного управления тест-кейсами. В этом разделе я перечислил максимальное количество возможных полей. Однако рекомендуется использовать только те, которые применяются вашей командой. А если в этом списке нет каких-то полей, используемых вашей командой, смело добавляйте их в ваш индивидуальный шаблон.
Стандартные поля шаблона тест-кейса
ID тест-кейса. У каждого тест-кейса должен быть уникальный ID. В этом идентификаторе может быть зашифрован тип тестов (в соответствии с соглашениями). Например, “TC_UI_1” означает “Тест пользовательского интерфейса № 1”.
Приоритет теста (низкий/средний/высокий). Это очень пригодится во время выполнения теста. Приоритет тестирования бизнес-правил и функциональных тестов может быть средним или более высоким, в то время как незначительные случаи пользовательского интерфейса могут иметь низкий приоритет. Приоритеты тестирования всегда должны устанавливаться рецензентом.
Название модуля. Упомяните название основного модуля или подмодуля.
Автор теста. Имя тестировщика.
Дата разработки теста. Дата, когда он был написан.
Тест выполнен. Имя тестировщика, выполнившего данный тест. Заполняется только после выполнения теста.
Дата выполнения теста. Дата, когда тест был выполнен.
Название теста. Название тест-кейса. Например, проверка страницы входа в систему с действительным именем пользователя и паролем.
Резюме/описание теста. Краткое описание предназначения теста.
Предварительные условия. Любые предварительные условия, которые должны быть соблюдены перед выполнением данного варианта теста.
Зависимости. Укажите любые зависимости от других тест-кейсов или требований к тестам.
Шаги теста. Подробно перечислите все этапы выполнения теста. Напишите шаги теста в том порядке, в котором они должны быть выполнены. Обязательно укажите как можно больше деталей.
Профессиональный совет: Чтобы эффективно управлять тест-кейсом с меньшим количеством полей, используйте это поле для описания условий тестирования, тестовых данных и ролей пользователей для выполнения теста.
Тестовые данные. Тестовые данные, которые используются в качестве входных для данного тест-кейса. Вы можете предоставить различные наборы данных с точными значениями. Примечание редакции: у нас есть отдельная статья об управлении тестовыми данными.
Ожидаемый результат. Какими должны быть выходные данные или поведение системы после выполнения теста? Подробно опишите ожидаемый результат, включая сообщение/ошибку, которая должна быть выведена на экран.
Постусловие. Каким должно быть состояние системы после выполнения данного тест-кейса?
Фактический результат. Фактический результат теста должен быть заполнен после его выполнения. Опишите поведение системы после выполнения теста.
Статус (пройден/не пройден). Если фактический результат не соответствует ожидаемому, отметьте этот тест как неудачный. В противном случае отметьте его как пройденный.
Примечания/комментарии/вопросы. Если существуют какие-либо особые условия для поддержки вышеуказанных полей, которые не могут быть описаны выше, или если есть какие-либо вопросы, связанные с ожидаемыми или фактическими результатами, то укажите их здесь.
Дополнительные поля
При необходимости добавьте следующие поля:
Идентификатор дефекта/ссылка. Если тест не пройден, то укажите ссылку на журнал дефектов или укажите номер дефекта.
Тип теста/ключевые слова. Это поле можно использовать для классификации тестов по типам. Например, функциональные, юзабилити, бизнес-правила и т.д.
Требования. Требования, для которых пишется данный тест-кейс. Желательно указать точный номер раздела в документе с требованиями.
Приложения/ссылки. Это поле полезно для сложных сценариев тестирования, чтобы объяснить шаги теста или ожидаемые результаты, используя диаграмму Visio в качестве ссылки. Укажите ссылку или местоположение фактического пути к диаграмме или документу.
Автоматизация (Да/Нет). Автоматизирован ли данный тест-кейс. Когда тест-кейсы автоматизированы, полезно отслеживать статус автоматизации.
Примечание редакции: также рекомендуем почитать “Как подготовиться к написанию тест-кейсов”.
Пример тест-кейса для ручного тестирования
Ниже приведен пример реального проекта, который демонстрирует, как реализуются все перечисленные советы и приемы.
Заключение
Лично я предпочитаю работать с тест-кейсами с применением специального инструмента. Вы можете начать с инструмента с открытым исходным кодом. Он поможет вам в организации процесса тестирования и, кроме того, сэкономит много времени, избавив от необходимости вручную вести эти документы.
Перевод статьи “Sample Test Case Template With Test Case Examples”