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

Что такое бесплатные шаблоны тестовой документации?

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

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

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

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

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

Документы в тест-наборе

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

Тестовая стратегия. Как эта организация тестирует в целом. Один раз написано, редко пересматривается, применяется ко всем проектам.

Тест-план. Что будет тестироваться в этом релизе или проекте, в каких средах, кем, с какими критериями входа и выхода и по какому графику.

Тест-кейсы. Отдельные проверки. Шаги и, что особенно важно, ожидаемые результаты.

Тестовые скрипты. Автоматизированный эквивалент, когда кейс закодирован, а не выполнен человеком.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С шаблонами тестовой документации вы можете:

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

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

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

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

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

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

Ожидаемый результат — это тест-кейс

Откройте любой тестовый набор и посмотрите, где находятся слова.

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

Затем посмотрите на ожидаемый результат. Там будет что-то вроде: возврат успешно обработан.

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

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

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

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

Как написать ожидаемый результат, который может не пройти

Три свойства, и их легко проверить на уже существующем наборе.

Он называет состояние, а не впечатление. Не «запись сохраняется корректно», а «запись появляется в списке со статусом Active и изменённым timestamp в течение последней минуты».

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

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

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

Что должен содержать шаблон тест-кейса

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

Различие между «заблокирован» и «не запускался» важнее, чем кажется. Набор, который сообщает о 90% прохождения, мог выполнить только 60% своих кейсов, и разница будет незаметна, если всё, что не прошло, записывается одинаково.

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

Заполнено реальным примером, а не плейсхолдерами. Система — это платформа обработки платежей.

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

Тест-план, в общих чертах. Область: обработка возвратов для релиза 4.9. В области: полные возвраты, частичные возвраты, возвраты по урегулированным и неурегулированным транзакциям. Не в области: чарджбэки, они не меняются. Среды: staging с объёмами данных, похожими на production. Критерии входа: деплой сборки, smoke-тест пройден, тестовые данные загружены. Критерии выхода: все кейсы с приоритетом один пройдены, нет открытых дефектов с приоритетом один или два, сверка ledger чистая по всему прогону.

Тест-кейс.

Идентификатор: TC-118. Название: Полный возврат по урегулированной транзакции создаёт ровно одну запись о возврате.

Приоритет: Один.

Предусловия: существует учётная запись мерчанта M-4471 с урегулированной транзакцией T-88210 на 240.00. Баланс ledger для M-4471 зафиксирован до начала. У тестировщика есть права на возврат.

Шаги.

1. Откройте экран платежей и найдите T-88210.

2. Выберите транзакцию и выберите «Возврат».

3. Введите 240.00 и подтвердите.

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

Существует одна запись о возврате против T-88210 и только одна. Проверено в таблице возвратов, а не в интерфейсе.

Баланс ledger мерчанта для M-4471 уменьшился ровно на 240.00 относительно зафиксированного стартового значения. Проверено в отчёте ledger.

В выписке мерчанта за период отображается одна строка возврата на 240.00.

Статус транзакции в интерфейсе показывает Refunded.

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

Фактический результат: записан во время выполнения, с наблюдёнными значениями ledger, а не предположениями.

Статус: пройден, не пройден, заблокирован или не запускался.

Доказательства: результат запроса из таблицы возвратов и копия строки отчёта ledger.

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

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

Пример тестовой документации: триста тридцать восемь прохождений

Brayford Payments обрабатывает карточные платежи для небольших мерчантов и работает примерно с двумя сотнями сотрудников. Они выпустили обновлённый сценарий возвратов.

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

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

Кейс TC-118 покрывал возвраты. В нём было семь подробных шагов и ожидаемый результат: возврат успешно обработан.

Тестировщик выполнил все семь шагов, увидел сообщение о подтверждении и статус Refunded, и записал «пройдено». Это было корректное применение документа, который был перед ним.

Никто не смотрел на ledger. В самом кейсе их об этом не просили. Один возврат и двойной возврат выглядят одинаково на экране подтверждения — именно поэтому проверка должна была происходить где-то ещё.

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

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

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

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

Рост этого числа — и есть результат. Дефекты в production за следующие шесть месяцев снизились с одиннадцати до двух.

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

Как писать тест-кейсы за шесть шагов

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

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

3. Спросите, как это может пройти, оставаясь неправильным. Если вы можете ответить, ожидаемый результат должен иметь ещё одно условие.

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

5. Фиксируйте предусловия, включая данные. Большинство неудач воспроизведения дефекта связано с другими данными, а не с другими шагами.

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

Шаг первый — это вся методика. Шаги два и три — это то, что ловит дефекты, которые доходят до production.

Тест-кейсы против тестовых сценариев

Эти два понятия используют взаимозаменяемо, а разница — в уровне детализации.

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

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

Полезная дисциплина — сначала писать сценарии, согласовывать покрытие по ним с людьми, которые понимают бизнес, а затем писать кейсы «под ними». Если сделать наоборот, получится набор, который покрывает всё, что пришло в голову человеку, который его писал.

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

Тестовая стратегия, тест-план и план QA

Три документа выше тест-кейсов, и различия имеют практический вес.

Тестовая стратегия — организационный документ, который живёт долго. Как мы тестируем, какие типы тестирования используем, каковы наши стандарты. Он применяется ко всем проектам и редко пересматривается.

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

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

Практический тест — это тайминг. Активности, происходящие до того, как работа сделана, — это гарантия. Активности после — это контроль, а тестирование — это контроль.

Что бесплатные шаблоны тестовой документации не могут исправить

Требования, с которыми никто не согласился. Тест-кейс проверяет поведение относительно ожидания, и если ожидание никогда не было согласовано, тестировщики пишут кейсы, опираясь на собственное предположение о том, каким оно должно быть.

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

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

Тестовые данные, которые не представляют production. Дефект Brayford требовал конкретного условия по времени и реалистичного объёма данных. Ни того, ни другого не было в тестовой среде, и ни один шаблон это не решает.

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

Покажите тест, а не описывайте его

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

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

Вторая проблема в том, что новый тестировщик, присоединяясь к команде, учится тому, что значит «проверять правильно», наблюдая за кем-то, и если у людей нет времени, он учится по документам — а именно оттуда и берётся оптимистичное прочтение.

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

Запишите это. Оформите в фирменном стиле. Переведите. Trupeer it.

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

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

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

Есть ли бесплатная загрузка шаблона Excel для тест-кейсов?

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

Стоит сделать две добавки. Колонка, где фиксируется проверка ожидаемого результата — то есть интерфейс, база данных, отчёт или система ниже по цепочке. И отдельные значения статуса для «заблокирован» и «не запускался», потому что их объединение скрывает, сколько из набора было реально выполнено.

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

Да, и «простая» обычно — правильный выбор. Простой макет шаблона тест-кейса Excel с идентификатором, названием, приоритетом, предусловиями, шагами, ожидаемым результатом, фактическим результатом и статусом покрывает почти всё.

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

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

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

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

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

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

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

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

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

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

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

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

Читайте пример PDF тест-кейса по ожидаемым результатам, а не по структуре. Структура переносится откуда угодно. Важно другое: как реальная команда сформулировала, как выглядит «правильно», и находятся ли их проверки вне интерфейса — именно это стоит изучить.

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

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

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

Есть ли набор шаблонов документации для тестирования ПО?

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

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