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

Что такое бесплатный шаблон плана тестирования?

Бесплатный шаблон плана тестирования — это повторно используемая структура документа, в которой указано, что будет тестироваться в рамках конкретного релиза или проекта, в каких средах, кем, по какому графику и как вы поймете, что тестирование завершено.

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

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

Формат следует за применением. Бесплатный шаблон плана тестирования в Word подходит самому плану — это текст, который нужно просмотреть и согласовать, и для небольшого релиза достаточно простой разметки шаблона плана тестирования Word на одной-двух страницах. Бесплатный шаблон плана тестирования в Excel подходит для графика, матрицы покрытия и распределения ресурсов. Бесплатный шаблон плана тестирования в PDF — это утвержденная копия, прикрепленная к записи релиза, а пример документа плана тестирования PDF из опубликованного источника — лучший способ увидеть, как это должно выглядеть.

Планы тестирования читают один раз — а спорят о них позже

План тестирования пишут за недели до начала тестирования, когда никто не находится под давлением. Его спокойно просматривают, согласуют и подшивают.

Затем его читают снова ровно один раз: в тот день, когда кто-то хочет выпустить релиз, а тестирование еще не завершено.

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

Все критичные дефекты устранены. Регрессионный набор пройден. Подтверждение UAT получено.

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

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

Как настроить этот шаблон в Trupeer

Шаг 1: Откройте раздел «Шаблоны»

Перейдите в раздел «Шаблоны» из главной навигации.

Шаг 2: Выберите и откройте шаблон

Нажмите на любой шаблон, с которым хотите работать, чтобы открыть его.

Шаг 3: Разверните просмотр шаблона

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

Шаг 4: Отредактируйте шаблон

Нажмите «Изменить», чтобы начать редактирование выбранного шаблона.

В редакторе вы можете:

• Добавлять новые разделы

• Задавать или обновлять правила форматирования

• Добавить логотип и настроить его положение и связанные параметры

Шаг 5: Сохраните настроенный шаблон

После того как вы внесете все необходимые изменения, нажмите «Сохранить», чтобы сохранить обновленный шаблон как свой.

Шаг 6: Предпросмотр и точная настройка шаблона

Когда вы захотите увидеть, как выглядит ваш настроенный шаблон, откройте «Предпросмотр».

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

С шаблоном плана тестирования вы можете:

• Экономить часы на написании: пропускайте пустую страницу — структура уже создана для QA.

• Улучшать покрытие тестами: встроенные разделы гарантируют, что ничего критичного не будет упущено.

• Оставаться в рамках бренда: применяйте логотип, шрифты и цвета с помощью бренд-набора Trupeer.

• Стандартизировать планы для релизов: используйте один и тот же шаблон плана тестирования для каждого продукта и релиза.

• Быть готовыми к аудиту: согласовано с IEEE 829, ISO 29119 и аналогичными стандартами.

• Работать с глобальными командами: переводите планы тестирования на 65+ языков одним кликом.

Сначала запишите выходные критерии и укажите, кто может их отменять

Два изменения, оба недорогие — и это вся аргументация на этой странице.

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

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

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

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

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

Как сделать выходные критерии исполнимыми

Три свойства — и у большинства опубликованных критериев их нет.

Число. Не «регрессионный набор пройден», а «регрессионный набор: выполнено 100% кейсов приоритет 1, 95% пройдено, открытых ошибок приоритет 1 — 0». «Пройдено» и «выполнено» — разные вещи, и план, который не различает их, покажет 90% пройдено для набора, который был выполнен на 60%.

Проверяющий, который не находится под давлением. Классификация серьезности — слабое место в любом процессе тестирования, потому что люди, которые классифицируют дефекты, часто и хотят выпустить релиз. Если указать, кто назначает серьезность, и сделать это человеком вне линии поставки, убирается самый простой путь обойти критерий.

Названный уполномоченный на отмену. Как и выше: это должен быть другой человек, не владелец релиза.

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

Что должен содержать шаблон плана тестирования

Десять компонентов, и выходные критерии — первыми.

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

Бесплатный шаблон плана тестирования: структура, которую нужно копировать

Заполнено реальным примером, а не плейсхолдерами. Система — это ПО для точек продаж в магазинах у дома.

Скопируйте отсюда.

Выходные критерии. Записываются первыми, с числами, проверяющими и уполномоченным на отмену.

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

Входные критерии. Сборка развернута в staging. Дымовой тест пройден. Тестовые данные загружены и обновлены. Нет открытых дефектов приоритет 1 с предыдущего цикла.

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

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

Среды. Staging с базой данных, восстановленной из production-снимка большого набора магазинов. Четыре физических кассы двух поколений оборудования. Обратите внимание: в staging один сервер приложений, тогда как в production их шесть, поэтому поведение балансировки нагрузки не представлено — это указанный риск.

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

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

Ресурсы. Два тестировщика, полный рабочий день. Один инженер по производительности на три дня. Владелец бизнеса на два дня UAT. Если любого из тестировщиков отвлекут на поддержку, окно не выдерживается и критерий два становится первым под риском.

Риски. Один сервер приложений в staging. Один день на непредвиденные обстоятельства по графику. Интеграция лояльности от третьих лиц не тестировалась нами. Владелец бизнеса новый в должности.

Результаты. Выполненные результаты тестирования с доказательствами, отчеты о дефектах, отчет о сводке тестирования и подписанная запись об отмене, если таковая есть.

Скопируйте отсюда.

Пример плана тестирования: три дефекта приоритет 1, которые стали двумя

Danecroft Retail Systems поставляет ПО для точек продаж в магазины у дома и нанимает около ста восьмидесяти человек. Она выпустила крупную версию для парка из трехсот сорока магазинов.

План тестирования был обычным. Его выходные критерии читались так: все дефекты приоритет 1 устранены, регрессионный набор пройден, подтверждение UAT получено.

В день принятия решения о релизе открыты были три дефекта приоритет 1. Регрессионный набор был выполнен на 91%, и план не различал «выполнено» и «пройдено». UAT был подписан владельцем продукта, который работал в должности пять недель.

Менеджер релиза поднял этот вопрос с CTO. CTO спросил, действительно ли эти три дефекта имеют приоритет 1.

Два дефекта переклассифицировали на средний уровень во время той встречи. Третий приняли на основании того, что существует обходное решение.

Никто не лгал и никто ничего не отменял. В плане не было определения приоритет 1, не было указано, кто назначает серьезность, не было порога по выполнению регрессии и не было названного уполномоченного на отмену. Отменять было нечего, поэтому и фиксировать было нечего.

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

В ходе проверки выявили три конкретные слабости — все в выходных критериях и ни одной в тестировании.

Серьезность назначали люди, находившиеся под давлением, чтобы выпустить релиз. «Пройдено» и «выполнено» использовали как взаимозаменяемые, поэтому 91% звучало как процент прохождения. А подпись не называла конкретного человека и не содержала ничего о том, что именно они подтверждают.

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

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

Тестирование было достаточным. План не предоставлял механизма, чтобы тестирование вообще могло иметь значение.

Как написать план тестирования за шесть шагов

1. Сначала запишите выходные критерии, с числами, прежде чем делать что-либо еще в документе.

2. Назначьте проверяющего для каждого и убедитесь, что это не человек, чьи цели включают дату релиза.

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

4. Опишите область применения, включая то, что исключено, и объясните, почему каждое исключение допустимо.

5. Честно опишите среду, особенно там, где она отличается от production способами, которые могут скрыть дефекты.

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

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

Область применения и то, что вы не тестируете

Раздел «Не в области применения» — вторая по ценности часть плана тестирования, и в большинстве планов он занимает одну строку.

В нем должны быть три категории, и они разные.

Исключено намеренно, потому что это не меняется. Разумно и стоит указать причину, потому что «не меняется» — это предположение, которое иногда оказывается неверным.

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

Исключено, потому что это нельзя протестировать здесь. Поведение балансировки нагрузки, реальные платежные сети, объемы production-данных, реальная параллельность. Это честные пункты, и они должны появиться и в разделе «Риски», и в разделе «Область применения», потому что они называют дефекты, которые ваш процесс не может поймать.

Третья категория — та, которая предсказывает инциденты в production. Команда, которая может перечислить, до чего не дотягивается ее тестирование, — это команда, которая знает, куда смотреть, когда что-то идет не так.

План тестирования, тестовая стратегия или тест-кейс?

Три уровня, и путаница между ними встречается достаточно часто, чтобы сказать об этом прямо.

Тестовая стратегия — организационный документ. Как эта компания тестирует, какие типы тестирования использует, какие стандарты применяются. Написано один раз — применяется ко всем проектам.

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

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

Над всеми тремя находится план QA, который охватывает все действия, направленные на предотвращение дефектов, а не на их поиск: обзор требований, определение «готово», стандарты code review. Шаблон плана QA описывает это различие. Если ваш план QA содержит только тестирование, вы написали план тестирования с более широким названием.

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

Варианты плана тестирования

Структура сохраняется, а акценты смещаются.

Agile или планы тестирования по спринтам. Обычно они намного короче, часто это одна страница, и нередко они включены в определение «готово». Аргументация по выходным критериям применяется без изменений и становится важнее, потому что решение повторяется каждый спринт.

Планы приемочного тестирования пользователями (UAT). Выходной критерий — это подпись человека, поэтому укажите, что именно они подтверждают, что лично сделали. Подпись в документе, который никто не читал, — самый слабый контроль в распространенном использовании.

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

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

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

Что бесплатный шаблон плана тестирования не может исправить

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

Среду, которая не может выявить дефект. Ни один бесплатный шаблон плана тестирования не даст вам объемы production-данных или реальную параллельность.

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

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

Покажите, что тестирование действительно было

Выходные критерии зависят от доказательств, и в большинстве организаций доказательства — это колонка со статусом.

Регрессионный набор был запущен. Кто-то поставил галочки в кейсах. То, выполнялся ли каждый кейс так, как написано, и что именно наблюдали, нигде не фиксируется, а значит, критерий «100% выполнено» держится на утверждении, а не на записи. После инцидента это утверждение и проверяют, и обычно его нельзя подтвердить ни так, ни иначе.

Trupeer AI формирует запись как побочный продукт. Запись прогона тестов дает письменный обход с уже сделанными и размещенными скриншотами — вместе с видео — в вашем собственном брендинге. То, что наблюдали на каждом шаге, существует, а не просто утверждается, и именно это нужно проверяющему, чтобы честно подписать критерий.

Фиксируйте это. Оформляйте в бренде. Переводите. Trupeer it.

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

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

Часто задаваемые вопросы

Есть ли бесплатная версия шаблона плана тестирования в Word?

Word подходит самому плану, потому что большая часть — это текст, который нужно просмотреть и согласовать, и потому что обычно требуется утверждение. Файл шаблона плана тестирования Word — правильный рабочий формат.

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

Есть ли простой шаблон плана тестирования в Word?

Да, и для небольшого релиза или одного спринта простой файл шаблона плана тестирования Word на одной-двух страницах полностью подходит.

Сократите разделы «Подход» и «Ресурсы» перед тем, как сокращать выходные критерии. План на одну страницу с числовыми критериями, назначенным проверяющим и уполномоченным на отмену стоит больше, чем план на пятнадцать страниц без них.

Есть ли бесплатная версия шаблона плана тестирования в Excel?

Excel подходит для табличных частей плана тестирования: графика, матрицы покрытия, распределения ресурсов и самой таблицы выходных критериев. Файл шаблона плана тестирования Excel хорошо справляется с этим.

Разделы «Область применения», «Подход» и «Риски» — это текст, и им место в документе. Разделить план на два файла — нормально, если один ссылается на другой и только один из них является утвержденной версией.

Есть ли бесплатная версия шаблона плана тестирования в PDF?

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

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

Где найти пример документа плана тестирования PDF?

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

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

Есть ли бесплатная загрузка шаблона плана тестирования, которую стоит использовать?

Список разделов стабилен уже десятилетия, поэтому бесплатная загрузка шаблона плана тестирования экономит вам немного, и каждая версия предлагает примерно одну и ту же структуру.

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

Что должны говорить выходные критерии на самом деле?

Числа, проверяющие и уполномоченный на отмену. Не «регрессионный набор пройден», а «выполнено и пройдено 100% кейсов приоритет 1, проверено руководителем QA, отмене не подлежит».

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

Кто должен писать план тестирования?

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

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