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

Введение

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

Основные тестовые артефакты:

План тестирования (Test Plan)

Это документ, который описывает общий план и стратегию тестирования проекта. Он играет ключевую роль в организации и управлении процессом тестирования. Вот как его составить и из каких основных пунктов он состоит:
  • 1
    Введение Introduction
    Краткое введение в документ, указание его цели и области применения.
  • 2
    Цели и область тестирования Objectives and Scope
    Определение целей тестирования и описание, что включено в область тестирования, а также что не включено.
  • 3
    Стратегия тестирования Test Strategy
    Описание общего подхода к тестированию, включая методы, инструменты и ресурсы, которые будут использоваться.
  • 4
    Описание проекта Project Overview
    Информация о проекте, его цели, архитектуре, технологиях и особенностях.
  • 5
    Роли и обязанности Roles and Responsibilities
    Определение ролей участников процесса тестирования и их обязанностей.
  • 6
    График тестирования Test Schedule
    Указание временных рамок и сроков для проведения различных видов тестирования.
  • 7
    Риски и ограничения Risks and Limitations
    Описание потенциальных рисков и ограничений, которые могут повлиять на тестирование, и планы по их управлению.
  • 8
    Требования к тестированию Testing Requirements
    Определение требований к тестированию на основе документации по требованиям к продукту.
  • 9
    Тестовые окружения Test Environments
    Описание сред, в которых будут проводиться тесты, включая аппаратное и программное обеспечение.
  • 10
    Критерии завершения Exit Criteria
    Условия, которые должны быть выполнены, чтобы завершить тестирование определенного этапа или проекта.
  • 11
    Аппаратные и программные ресурсы Hardware and Software Resources
    Перечень ресурсов, необходимых для тестирования, включая оборудование, инструменты и лицензии.
  • 12
    Метрики и измерения Metrics and Measurements
    Параметры, которые будут использоваться для измерения качества тестирования и продукта.
  • 13
    Коммуникация и отчетность Communication and Reporting
    Как будет осуществляться обмен информацией между участниками и какие будут созданы отчеты.
  • 14
    Подписание и утверждение Sign-off
    Место для подписей и утверждений со стороны всех заинтересованных сторон.

Чек-лист (Checklist)

Это структурированный список задач, шагов или критериев, которые необходимо выполнить или проверить в процессе тестирования для обеспечения полноты и точности проверки. Основные составляющие чек-листа:
  • 1
    Определение цели и области
    Уточните, для чего вы создаете этот чек-лист и какую область он будет покрывать.
  • 2
    Сбор требований
    Понимание требований к продукту или функциональности, которую вы будете проверять.
  • 3
    Структурирование списка
    Разбейте чек-лист на разделы или категории, чтобы упорядочить задачи и упростить ориентацию.
  • 4
    Определение приоритетов
    Установите приоритеты для каждой задачи в чек-листе, чтобы определить, что следует проверить сначала.
  • 5
    Проверка точности
    Пересмотрите чек-лист, чтобы убедиться, что все задачи ясно сформулированы и ничего не упущено.
  • 6
    Тестирование чек-листа
    Пройдите через чек-лист самостоятельно, чтобы убедиться, что он логичен и полноценен.
  • 7
    Внесение коррекций
    Если необходимо, внесите коррекции или дополнения на основе реального опыта проверки.
  • 8
    Совместное использование
    Делитесь чек-листом с другими членами команды для обеспечения единого подхода.
  • 9
    Обновление
    По мере изменений в продукте или процессе тестирования, обновляйте и дорабатывайте чек-лист.
  • 10
    Документация
    Сохраните чек-лист в виде документа или в специализированных инструментах для тестирования.
  • 11
    Рефакторинг
    Периодически пересматривайте и улучшайте чек-лист с учетом обратной связи и нового опыта.
    Создание чек-листа помогает структурировать и упорядочить процесс тестирования, обеспечивая более полное и систематичное покрытие всех необходимых аспектов.

Тест-кейс (Test Case)

Это документ, который описывает шаги, условия и ожидаемый результат для проведения конкретного тестирования. Он служит для систематизации и стандартизации процесса тестирования, а также обеспечивает однозначное понимание того, как тестировщик должен проверить определенную функциональность. Вот как составить тест-кейс по пунктам:
  • 1
    Название тест-кейса
    Задайте краткое и информативное название, описывающее тестируемую функциональность. Оно должно быть понятно разработчикам и другим членам команды.
  • 2
    Идентификация
    Уникальный идентификатор тест-кейса, например, номер или код. Если мы пишем тест-кейс в какой-либо программе, например Testrail или Zephyr, номер обычно указывается автоматически.
  • 3
    Предусловия
    Условия, которые должны быть выполнены до начала тестирования. Например мы должны быть предварительно авторизованы в системе, или должны проверять функциональность на каком-то определенном браузере.
  • 4
    Шаги
    Последовательность действий, которые тестировщик должен выполнить:
    Шаг 1: Опишите первое действие.
    Шаг 2: Опишите второе действие.
    и т.д.
  • 5
    Ожидаемый результат
    Краткое описание того, что ожидается после выполнения каждого шага.
  • 6
    Приоритет
    Укажите, насколько важен этот тест в рамках общей тестовой стратегии (например, высокий, средний, низкий).
  • 7
    Время выполнения
    Приблизительное время, которое требуется для выполнения теста.
  • 8
    Статус
    Указание на текущий статус тест-кейса (например, в работе, пройден, не пройден).
  • 9
    Дата создания и автор
    Указание даты создания тест-кейса и имени автора.
  • 10
    Комментарии
    Дополнительные комментарии или заметки, которые могут быть полезными для понимания или исполнения тест-кейса.

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

Баг-репорт (Bug Report)

Это документ, который используется для фиксации и описания обнаруженных дефектов или проблем в программном продукте. Это важный инструмент для коммуникации между тестировщиками и разработчиками, позволяющий последним быстро и точно понять проблему и внести соответствующие изменения. Вот как составить баг-репорт по пунктам:
  • 1
    Заголовок
    Краткое и информативное название дефекта.
  • 2
    Идентификация
    Уникальный идентификатор баг-репорта, например, номер или код.
  • 3
    Описание
    Краткое описание проблемы, которую вы обнаружили.
  • 4
    Шаги воспроизведения
    Последовательность шагов, которые привели к возникновению дефекта:
    Шаг 1: Опишите первое действие.
    Шаг 2: Опишите второе действие.
    и т.д.
  • 5
    Ожидаемый результат
    Что вы ожидали увидеть после выполнения шагов воспроизведения.
  • 6
    Фактический результат
    Что фактически произошло после выполнения шагов воспроизведения.
  • 7
    Окружение
    Опишите окружение, в котором произошел дефект (операционная система, браузер, устройство и т. д.).
  • 8
    Серьезность
    Укажите, насколько важен этот дефект для продукта (Серьезности бывают: блокирующая, критическая, серьезная, несерьезная, тривиальная)
  • 9
    Приоритет
    Укажите, насколько быстро нужно взять в исправление этот баг (Приоритеты бывают: высокий, средний, низкий).
  • 10
    Статус
    Указание на текущий статус баг-репорта (например, новый, в работе, решен, отклонен).
  • 11
    Срок решения
    Предполагаемый срок, в течение которого ожидается решение проблемы.
  • 12
    Скриншоты и/или видео
    Если возможно, предоставьте визуальное подтверждение дефекта.
  • 13
    Дополнительные детали
    Любая дополнительная информация, которая может помочь разработчикам понять и решить проблему, например ссылка на нужные логи.
  • 14
    Дата создания и автор
    Указание даты создания баг-репорта и имени автора.

    Создание подробного и точного баг-репорта поможет команде разработчиков быстро и эффективно устранить дефекты, а также обеспечит более качественную работу над продуктом

Серьезность и приоритет в баг-репорте

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

Какие уровни серьезности бывают в баг-репортах:

1
Блокирующая (Blocker)
Дефект, который полностью блокирует работу продукта, вызывает крах или безопасность системы. Продукт становится неиспользуемым.
2
Критическая (Critical)
Дефект, который полностью блокирует работу продукта, вызывает крах или безопасность системы, но у нас есть хотя-бы один другой путь обхода. Например, у нас сломалась прямая авторизация, но мы можем войти с помощью кнопки «войти через Google».
3
Высокая (Major)
Дефект, который серьезно влияет на функциональность продукта и вызывает неполадки. Пользователь может испытывать значительные трудности при использовании продукта.
4
Средняя (Minor)
Дефект, который влияет на функциональность продукта, но не вызывает критических сбоев. Пользователь может столкнуться с небольшими неудобствами.
5
Тривиальная (Trivial)
Дефект, который имеет небольшой или минимальный эффект на функциональность продукта. Продукт остается полностью пригодным для использования.
6
Неопределенная (Uncategorized)
Дефект, для которого сложно определить серьезность из-за неясности влияния на продукт или его использование.
Оценка серьезности дефекта позволяет команде разработчиков и тестировщиков определить, какие проблемы нужно решать в первую очередь, чтобы максимально удовлетворить потребности пользователей и обеспечить стабильность продукта.
Приоритеты в баг-репорте (Priority)
Это оценка важности устранения дефекта в программном продукте. Они помогают определить, насколько быстро следует исправить данный дефект относительно других задач.

Какие приоритеты бывают в баг-репортах:

1
Высокий (High)
Дефект, который оказывает существенное влияние на работу продукта и требует быстрого устранения. Важно устранить его до выпуска продукта.
2
Средний (Medium)
Дефект, который оказывает определенное влияние на функциональность продукта, но не является критическим. Может быть устранен в ближайших релизах.
3
Низкий (Low)
Дефект, который не сильно влияет на работу продукта и может быть отложен на длительный срок без негативных последствий.
Важно понимать, что серьезности в баг-репортах выставляют тестировщики, а приоритеты — проджект менеджер.
Заключение
План тестирования, чек-лист, тест-кейсы и баг-репорты играют ключевую роль в успешном процессе тестирования программного обеспечения. Эти документы обеспечивают структурированный и организованный подход к тестированию, помогая обнаруживать и устранять дефекты в продукте. Оценка серьезности и приоритетов в баг-репортах позволяет оптимально распределить усилия на исправление наиболее критичных проблем. Такой комплексный подход обеспечивает более высокое качество программного продукта и улучшает взаимодействие между командами разработки и тестирования. Эти инструменты становятся незаменимыми в сфере QA и способствуют достижению успеха в проектах разработки ПО.
Оставь заявку на получение помощи с трудоустройством в области тестирования. Наши опытные менторы помогут тебе преодолеть все трудности на твоем пути!
Made on
Tilda