First-Offer University

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

Введение

Занимая такую важную позицию в компании, как 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)

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

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

Блокирующая (Blocker)

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

Критическая (Critical)

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

Высокая (Major)

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

Средняя (Minor)

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

Тривиальная (Trivial)

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

Неопределенная (Uncategorized)

Дефект, для которого сложно определить серьезность из-за неясности влияния на продукт или его использование.

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

Приоритеты в баг-репорте (Priority)

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

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

Высокий (High)

Дефект, который оказывает существенное влияние на работу продукта и требует быстрого устранения. Важно устранить его до выпуска продукта.

Средний (Medium)

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

Низкий (Low)

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

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

Заключение

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

Виды, уровни и методы тестирования

Оставить заявку

Оставь заявку на получение помощи с трудоустройством в области тестирования. Наши опытные менторы помогут тебе преодолеть все трудности на твоем пути!