Тест план что это
Тестирование
Раздел: Тестирование > Тестовые Артефакты > Тест План (План тестирования)
Тест План (План тестирования)
Рекомендации по написанию Тест Плана
Каждая методология или процесс пытаются навязать нам свои форматы оформления планов тестирования. Предлагаю вам, как пример, шаблоны тест планов от RUP (Rational Unified Process) и стандарт IEEE 829:
Присмотревшись внимательнее становится ясно, что оба документа описывают одно и тоже, но в разной форме. В случае, если вам не подходит стандартный шаблон или вы решили придумать свой собственный, более подходящий для вас формат документа, то из опыта можем сказать, что хороший тест план должен как минимум описывать следующее:
Ответив в своем тест плане на вышеперечисленные вопросы, можно считать, что у вас на руках уже есть хороший черновик документа по планированию тестирования. Далее, чтобы документ приобрел более менее серьезный вид, предлагаем дополнить его следующими пунктами:
Виды тест планов
Чаще всего на практике приходится сталкиваться со следующими видами тест планов:
Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является «живым» документом, который постоянно претерпевает изменения, отражающие реальное положение дел на проекте.
В повседневной жизни на проекте может быть один Мастер Тест План и несколько детальных тест планов, описывающих отдельные модули одного приложения.
Рецензия и Утверждение
Для увеличения ценности вашего тест плана рекомендуется проводить его периодическое рецензирование со стороны участников проектной группы. Это можно сделать просто договорившись между собой или же реализовать в виде «процедуры утверждения». Как пример, приведем список участников проектной группы, утверждение которых мы считаем необходимым:
Каждый из перечисленных участников проекта, перед утверждением, проведет рецензию и внесет свои комментарии и предложения, которые помогут сделать Ваш тест план более полным и качественным.
Вывод
Воспользовавшись вышеуказанными советами, у вас будет больше шансов написать хороший документ, нежели придумывать все самим.
Как составить тест-план? Для начинающего тестировщика
Очень много ресурсов рассказывают про виды тестирования, как составить тест-кейсы и чек-листы, но очень мало ресурсов, особенно на русском рассказывают про составление тест-плана и для чего он нужен, а также сколько времени и сил он способен сберечь. Читая статьи и смотря видео по тестированию, рассказывают про некий тест-план, но очень часто вскользь, так давайте же вместе со мной разберем кратко про тест-план, а потом посмотрим на список ресурсов, которые помогут вам в этом.
Для себя я отметил следующие важные пункты при составлении тест-плана.
Основные пункты:
1 Краткое изложение проекта
В нескольких предложениях описать зачем и для кого этот продукт.
2 Понятная структура тест-плана
Расположить в правильном порядке все пункты тестированию
3 Сроки тестирования
Описать приблизительные сроки в формате когда и сколько времени будет потрачено на это.
4 Программы и методы тестирования
Рассказать какой софт и методы тестирования вы будете применять и для чего.
5 Технические требования
Например: Рассказать какие компьютеры или телефоны будут участвовать в тестировании (их характеристики)
6 Структура тестируемого проекта (Описать например какой функционал будет протестирован)
Описать все страницы проекта, какие функции там есть.
7 Результат тестирования
Что получилось в результате тестирования, какие тест-кейсы, чек-листы и т.д будут сделаны.
Полезные статьи с примерами и описанием как составить тест-план
Примеры тест-кейсов
Полезные видео с примерами составления
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Тест-план не для галочки, или 8 вопросов к заказчику на старте проекта
Практически на всех проектах, где мне довелось работать, был тест-план. Этот документ колоссально облегчал жизнь тестировщиков и делал ценность нашей работы для заказчика очевидной. Но есть одна деталь. Чтобы тест-план работал в интересах команды, надо составлять его с умом, при этом задавая правильные вопросы клиенту. Меня зовут Юрий Бабай, я сотрудничаю с ЕРАМ в роли Software Testing Team Leader. В этом материале поделюсь своими наработками для создания качественного тест-плана.
Иллюстрация Алины Самолюк
Краткий ликбез
Тест-план — это документ, который описывает все работы, которые будет производить команда тестирования на проекте. Он содержит риски, список нужных ресурсов, распорядок, описание различных процессов тестирования. Тест-план нужен, чтобы дать всем заинтересованным в проекте людям понимание:
Тест-план создают на начальной стадии проекта, когда идет сбор требований, формируется техническое задание, становится понятен объем работы и перечень задач. Не только стейкхолдеры, но и тест-лид (или просто наиболее опытный тестировщик на проекте), который пишет этот документ, сталкивается с вопросами. Ответы на них помогают прояснить заказчику, какие виды и уровни тестирования нужны в конкретном случае. И, собственно, «продать» этот сервис с максимальной прозрачностью процессов.
Тест-план покрывает все тестирование на проекте: функциональное, автоматизированное, тестирование безопасности и так далее. Общий документ называют Master Test Plan. Однако в некоторых ситуациях он может покрывать только один или несколько уровней тестирования. Это — Level Test Plan.
А можно без этого?
Если коротко — можно. Тест-план целесообразно писать для длительных проектов. Если ваш проект рассчитан на месяц-два, времени на обширную документацию нет и вы уверены, что не придется вводить в проект новых тестировщиков, тест-стратегии будет достаточно. Она может быть как составляющей частью тест-плана, так и отдельным документом, в котором описано, как именно вы будете проводить тестирование.
Например, на одном из проектов мы начинали разработку с бэкенд-части, поэтому фокус тестирования был смещен на API и работу с базой данных. Соответствующие виды тестирования были отражены в стратегии, которая была частью тест-плана. Спустя несколько месяцев заказчик решил добавить UI, и здесь тест-стратегия была представлена как отдельный документ, в котором основной фокус был направлен на тестирование пользовательского интерфейса. Это позволило акцентировать внимание заказчика непосредственно на изменениях в тестовых подходах и быстрее получить его согласие на них.
В долгосрочных проектах тест-план помогает выстраивать доверительные отношения с клиентом, показывая, что именно будет делать команда тестирования. Особенно полезно создавать такую документацию, если клиент новый. Если вы уже сотрудничаете с заказчиком много лет и работаете над типовыми проектами (например, e-commerce), то зачастую тест-стратегии будет достаточно.
Если все-таки решили создавать тест-план, сразу уточните у клиента: возможно, у него есть шаблон, которому стоит следовать. Если нет, можете использовать общепринятые стандарты: IEEE 829 Test Plan, RUP Test Plan. Мы в ЕРАМ создали собственный шаблон, который подходит для большинства заказчиков. Он основан на нашем опыте и в некоторых пунктах перекликается с мировыми стандартами.
Я считаю, что без тест-плана обойтись можно, но с ним работается лучше. И вот почему:
Создаем тест-план проекта: поэтапный разбор
Итак, вы решили, что тест-план вашему проекту все-таки нужен. Каждый подобный документ состоит из перечня типичных разделов.
Объем работ. В этот раздел надо включить все, что будете тестировать. Чаще всего это функционал от вашей команды разработки. Пропишите также зоны, качество которых вы проверять не будете (например, зону работы другого подрядчика). Это позволить обозначить границы ответственности: в них может входить интеграция с частями от других вендоров, но не качество чужого кода.
Приёмочные критерии. Укажите уровень качества, которому должен соответствовать продукт, чтобы заказчик его принял. Например, вы обязуетесь, что к моменту релиза не будет известных дефектов с приоритетом critical или major. Или утверждаете, что 80% тест-кейсов должно быть автоматизировано. Подобные критерии позволят клиенту понять, что продукт качественный и его можно отдавать конечным пользователям.
Риски. Здесь можно и нужно прописывать те негативные сценарии, которые могут произойти по ходу проекта. Типичные риски: вовремя не предоставлены тестовые данные, не работают компоненты от сторонних вендоров, нет нужного устройства для тестирования. Например, когда вышел iPhone X с фирменной «челкой» на экране, для многих команд в Украине это стало проблемой. Они не могли тестировать свои продукты перед релизом, потому что на украинском рынке нового устройства еще не было. Проектным менеджерам приходилось искать способы раздобыть девайс, чтобы тестировщики могли проверить продукт на реальном устройстве.
У каждого указанного риска должна быть прописана вероятность наступления, потенциальный ущерб, который он может нанести, ответственное лицо (иными словами, владелец риска), а также меры по предотвращению или работе с последствиями. Конечно, на старте проекта учесть абсолютно все не получится. Потому тест-план стоит дополнять в ходе работы.
Ресурсы. Во-первых, оборудование и/или устройства, которые понадобятся. Во-вторых, программы для тестирования, софт от Word и Excel до Visio и платных лицензий для автоматизации, приложения для менеджмента тест-кейсов (на многих проектах используют TestRail, и он платный).
Команда. Опишите, сколько людей понадобится. Какие у них должны быть знания и навыки, чтобы выполнить все задачи по тестированию. Если требуется, запланируйте тренинги и другое обучение.
Документация. Перечислите все типы документов, которые будете использовать на проекте. Уточните, что они будут включать. Это могут быть чек-листы, тест-кейсы с описанием базовых полей, отчеты, которые вы будете предоставлять заинтересованным лицам (проектным менеджерам, представителям клиента и другим). Укажите периодичность подготовки этих документов и ответственных лиц.
Стратегия. Это, пожалуй, самый интересный и объемный пункт. В стратегии должны быть указаны все виды тестирования, которые будут на проекте: функциональное и нефункциональное, тестирование после изменений, подходы к автоматизации, описание CI/CD pipeline, уровни тестирования и так далее.
В блоке с видами тестирования стоит указать, как каждый из них будет применяться на определенном этапе, какие инструменты потребуются. Например, тестирование производительности можно проводить на разных этапах проекта, но охватывать не все приложение, а только часть. Или, скажем, тестирование доступности порой применяют только к той части приложения, которую будет видеть конечный пользователь (для админ-части интернет-магазина оно будет слишком дорогим и ненужным). Однако учтите, что для некоторых приложений этот вид тестирования является обязательным. Например, в США веб-сайты федерального правительства обязаны быть доступны для людей с ограниченными возможностями. Это регулируется так называемой секцией 508.
Добавьте к стратегии также описание процесса тестирования. Уточните, работаете ли по Scrum или другой методологии, обозначьте этапы, на которых будете начинать тестирование. Перечислите, на каких устройствах, браузерах, расширениях экрана будете проводить проверки качества. Опишите жизненный цикл дефекта на вашем проекте. Все это поможет команде и клиенту быть на одной странице, видеть процесс одинаково и избежать многих недоразумений в будущем.
Расписание. Перечислите все ключевые даты, когда должно быть выполнено то или иное тестирование. Если при написании тест-плана четких дат нет, то сфокусируйтесь на майлстоунах, к которым можно привязаться (например, к такому-то моменту вы проведете регрессионное тестирование, подготовите определенные документы или отчеты). В случае со Scrum опишите ежедневно повторяющиеся активности, дополните список ключевыми датами релизов. Если в графике будут изменения, вносите их в тест-план динамично.
Восемь вопросов для качественного тест-плана
Эти вопросы я задаю заказчику или человеку, который его представляет, на старте нового проекта. Ценность каждого прочувствована на собственном опыте: без дополнительных уточнений можно упустить это из виду и привести команду и проект к проблемам.
Вопрос № 1: Интеграции с другими системами
На крупных проектах, где интеграций со сторонними системами много, нередко возникают сложности. Важно обозначить свою зону ответственности и понимать ее границы. Бывают ситуации, когда мы не можем проверить новый функционал. Еще хуже, когда на продакшене что-то перестает работать и обеспокоенный заказчик звонит среди ночи с просьбой исправить как можно скорее. А при детальном разборе оказывается, что дело не в вашей системе, а в трудностях интеграции или проблемах на стороне другого вендора.
В моей практике был такой случай: мы разрабатывали сервис для покупки авиабилетов. Информацию о доступных маршрутах нам предоставлял сторонний сервис. В один «прекрасный» день у него поменялся API на тестовых окружениях во время того, как заказчик проводил UAT-тестирование перед релизом на продакшн. Очень скоро я обнаружил у себя на почте множество гневных писем от клиента и проектного менеджмента: мол, как мы могли допустить такой продукт на UAT? Реальную причину инцидента мы выяснили только после расследования ситуации: вендор поменял формат данных без предупреждения, и наше приложение перестало их «понимать». Из этой ситуации следует вывод, что перед релизами лучше перестраховаться и узнать у остальных вендоров насчет изменений в контрактах сервисов или запланированном обслуживании систем.
Вопрос № 2: Нефункциональные требования к приложению
Прояснение этого пункта значительно влияет на тестовую стратегию. Заказчики часто упускают нефункциональные требования. Скорость работы, безопасность и доступность приложения, требования к локализации и интернационализации, особые пожелания (например, поиск по каталогу интернет-магазина не дольше двух секунд). Эти и другие требования важно выяснить на этапе планирования, чтобы понимать бюджет, состав команды и части приложения, к которым будут выдвинуты самые строгие требования. Это поможет обезопасить команду после выхода в продакшн: на вопросы и претензии заказчика будете отвечать конкретными документами.
Как правило, нефункциональные дефекты очень дорогие в исправлении. Обращайте внимание на необходимые клиенту производительность, доступность, безопасность.
Вопрос № 3: Тестовые данные
Этот вопрос, увы, часто задают слишком поздно, уже перед самым тестированием. Но что делать, если заказчик не может предоставить необходимую информацию так быстро? Скажем, большие объемы данных надо специально сгенерировать для вас, сделать их максимально похожими на те, которые будут использоваться в продакшене, и заодно замаскировать личную информацию пользователей (номера паспортов, страховки, водительских прав и тому подобное).
Важность этого вопроса я прочувствовал на своем опыте. Однажды запросил тестовые данные за месяц до непосредственного тестирования. Но на их подготовку потребовалось два с половиной месяца, это заблокировало часть работы и, как вы понимаете, никого не обрадовало. Оказалось, что у этого клиента никогда не возникало подобных запросов, потому службе поддержки пришлось строить процесс генерации тестовых данных практически с нуля.
Вопрос № 4: Конечные пользователи
Этот момент может ощутимо повлиять на ваше приложение. Например, у вас специфическое решение, созданное для людей, которые знакомы с его ранней версией. Для них подсказки по использованию могут быть излишними, они уже знают, какая функция и для чего нужна. А вот если уровень пользователей разный, то подсказками и инструкцией пренебрегать не стоит. И это тоже дополнительная работа для команды тестирования.
Кроме того, если приложение будет доступно пользователям из разных стран, надо проверить, какие требования есть на законодательном уровне (например, приложение должно быть доступным для пользователей с ограничениями по зрению или слуху). Важно понимать и то, на каких устройствах люди будут использовать ваш продукт.
Некоторые сервисы, такие как StatCounter или Google Analytics, позволяют получить эту статистику в зависимости от географии. Это поможет сфокусировать усилия команды тестирования и не распыляться на ненужные версии. Скажем, 90% процентов наших юзеров использует версию Android и только 5% — версию 6. В таком случае на старте мы будем держать на радаре Android 10. Бывают и ситуации, когда основная масса конечных пользователей в силу рабочих особенностей использует сугубо устройства с Android 4.1. Чтобы прояснить такие тонкости, надо задавать вопросы.
Вопрос № 5: Устройства для тестирования
Этот вопрос становится ребром на середине процесса разработки. Часто, если под рукой нет нужного устройства, можно купить его или просто написать письмо на другие отделы и одолжить девайс ненадолго. Но бывают исключительные ситуации.
Однажды мы делали проект для крупной киностудии. Пробы актеров ее сотрудники записывали на профессиональные камеры, видео с них должны были конвертироваться с помощью специального устройства и только потом попадать в наше приложение. Найти этот конвертирующий девайс в Украине на тот момент было невозможно. О его важности для тестирования мы узнали за пару дней до завершения разработки, а потом еще месяц ждали, пока устройство дойдет от клиента до нас. Это повлияло на сроки. Потому, когда пишете тест-план, задумывайтесь, какие устройства понадобятся, и обсуждайте заранее с проектным менеджером и клиентом, удастся ли обойтись эмуляторами или все-таки надо приобрести нужный девайс заранее.
Вопрос № 6: Ограничения со стороны клиента
Выясните, какие процессы в компании клиента отличаются от ваших. Возможно, вы узнаете об ограничениях в инструментах тестирования. В моей практике был случай, когда у заказчика был определенный набор софта и библиотек для автоматизации. Это внесло коррективы в расписание, потому что нашим тестировщикам надо было изучить некоторые с нуля. Из-за того, что мы не обсудили этот момент на старте, ситуация повлекла за собой переработки. Теперь задаем вопрос об ограничениях всегда.
Вопрос № 7: UAT/Beta-тестирование
На одном из финальных этапов продукт важно показать небольшой группе пользователей или тестировщикам клиента. Иногда для этого необходима специальная документация. Помню, как один заказчик решил провести UAT-тестирование со своей командой и попросил наши тест-кейсы. Однако изначально мы это не оговаривали, поэтому тест-кейсы были высокоуровневыми. Для нас информации было достаточно, некоторые вещи мы воспринимали как само собой разумеющиеся, а вот клиенту не хватало деталей. В итоге пришлось в авральном режиме дорабатывать документацию. Снова же: это переросло в опыт. Теперь на этапе создания тест-плана мы уточняем уровень детализации тест-кейсов.
Вопрос № 8: Аудит со стороны заказчика
У некоторых заказчиков есть свой отдел QA, и однажды он может прийти к вам с аудитом. Уточните на старте проекта, какие требования к документации выдвигает клиент, есть ли у него шаблоны. Это поможет вам не только удовлетворить свои потребности в документации, но и избежать инцидентов с несоответствием стандартам.
В заключении напомню, что тест-план — это динамический документ. Он требует регулярного обновления и наверняка пригодится на долгоиграющем проекте. Если у вас есть собственные рекомендации к составлению качественного тест-плана, делитесь в комментариях. Буду рад обмену опытом!
Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.