Close
Software Test Studio logo

Software Test Studio

Назад Далее

Тест-план, чек-лист, тест-кейс, баг-репорт — главные документы для QA Engineer

image

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

Тест-план

Театр начинается с вешалки, а тестирование - с тест-плана

Как понять, какой объём работ необходимо осуществить, как спланировать время на выполнение задач, определить техники, подходы и стратегии тестирования? Эти все нюансы прописаны в тест-плане, который составляет Test Lead после изучения проектной документации, требований и иных сопроводительных документов.

Тест-план создаётся в начале проекта, но с учётом согласованности с общим проектным планом и возможности внесения каких-либо изменений. Это объёмный и очень важный для QA Engineer документ, на основании которого будет строиться его работа.

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

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

Тест-план помогает организовать слаженную работу над проектом, предусмотрев все риски и не упустив важные моменты. Ознакомившись с тест-планом, узнав объём работы и приоритет выполнения задач, QA может приступать к следующему этапу - написанию чек-листов.

Чек-лист

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

Зачем тестировщику чек-листы?

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

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

Тест-кейс

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

Тест-кейсы - пошаговая инструкция проверки приложений

Тест-кейсы разрабатываются на основании чек-листов в такой последовательности от простого к сложному: простые позитивные - простые негативные - сложные позитивные - сложные негативные. За разработку тест-кейсов стоит браться до выхода первого билда, чтобы успеть их сделать до активной стадии тестирования. QA оформляют этот вид документа в Excel, Google-документах или с помощью специализированных инструментов (Test Link, TestRail, Jira и так далее). Стандартный тест-кейс должен включать следующую информацию: номер тест-кейса (ID), его приоритет и связанное с ним требование, названия модуля и подмодуля приложения, заглавие и условия выполнения, а также ожидаемый результат (как должно быть по документам).

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

Баг-репорт

Баг-репорт: что делать с найденным дефектом?

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

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

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

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

Все о тестировании