--- title: Документация и тест-план questionDates: q-transfer-0393: '2026-10-01' q-transfer-0394: '2026-10-01' q-transfer-0405: '2026-10-01' seo: description: >- Тема «Документация и тест-план» для собеседования QA. Зачем нужна тестовая документация? Какие её виды? Что такое тест-план? Какие элементы у него есть? title: Документация и тест-план — QA --- [Все темы QA](/prep/qa) ## Зачем нужна тестовая документация? Какие её виды? [#q-14bee738d69b818ba30bc0e654e11794] Тестовая документация необходима для организации и систематизации процесса тестирования ПО. Её основные виды включают: 1. Тест-планы: Описывают общую стратегию тестирования, включая цели, ресурсы, расписание и методы. 1. Тест-кейсы: Детализируют конкретные шаги, условия и ожидаемые результаты для выполнения определённых тестов. 1. Тест-скрипты: Подробные инструкции для автоматизированных тестов, определяющие взаимодействие с системой и ожидаемые ответы. 1. Отчёты о тестировании: Резюме результатов тестирования, включая найденные дефекты, выполненные тест-кейсы и общую оценку качества ПО. Эти документы помогают структурировать и контролировать процесс тестирования, обеспечивая повышение качества и надёжности разрабатываемого программного продукта. :::note[Ссылки для изучения] 1. [Тестовая документация: рабочие продукты по этапам — ISTQB CTFL, PDF, раздел 1.4.3](https://www.rstqb.org/files/content/rstqb/downloads/ISTQB%20Downloads/ISTQB_CTFL_Syllabus-v4.0.1-RU-1.pdf#page=21) 2. [Тестовая документация и тест-план. Artsiom Rusau QA Life, с 2:18](https://www.youtube.com/watch?v=LIpXj68VVCo&t=138s) ::: --- ## Что такое тест-план? Какие элементы у него есть? [#q-14bee738d69b8133aef7e1075b65e65e] Тест-план — это документ, описывающий общую стратегию и подход к тестированию конкретного продукта или проекта. Основные элементы тест-плана включают: 1. Введение: Обзор целей и области применения тест-плана. 1. Цели и задачи: Чётко сформулированные цели, которые должны быть достигнуты в процессе тестирования. 1. Стратегия тестирования: Описание подхода к тестированию, включая методы, типы тестирования, используемые инструменты и техники. 1. Область тестирования: Уточнение функциональных и нефункциональных аспектов продукта, подлежащих тестированию. 1. Ресурсы и расписание: Определение людских, материальных и временных ресурсов, необходимых для выполнения тестирования. 1. Ожидаемые результаты: Описание ожидаемых выходных данных и критериев приёмки для успешного завершения тестирования. 1. Стратегия управления рисками: План действий по управлению и минимизации рисков, связанных с тестированием. 1. Обзор и аппробация: Подтверждение и согласование тест-плана с заинтересованными сторонами перед началом тестирования. Тест-план помогает организовать и структурировать процесс тестирования, обеспечивая эффективное и систематическое тестирование продукта. :::note[Ссылки для изучения] 1. [Цель и содержание тест-плана — ISTQB CTFL, PDF, раздел 5.1.1](https://www.rstqb.org/files/content/rstqb/downloads/ISTQB%20Downloads/ISTQB_CTFL_Syllabus-v4.0.1-RU-1.pdf#page=53) 2. [Содержание тест-плана. Artsiom Rusau QA Life, с 4:36](https://www.youtube.com/watch?v=LIpXj68VVCo&t=276s) ::: --- ## Что включить в тест-план, как его поддерживать и когда он нужен? [#q-14bee738d69b81a4b9d6c96166924a0e] Тест-план должен обязательно содержать следующую информацию: 1. Цели тестирования: Чётко сформулированные цели и задачи, которые должны быть достигнуты в процессе тестирования. 1. Стратегия тестирования: Описание подхода к тестированию, включая используемые методы, типы тестирования, инструменты и техники. 1. Область тестирования: Уточнение функциональных и нефункциональных аспектов продукта, подлежащих тестированию. 1. Ресурсы и расписание: Определение людских, материальных и временных ресурсов, необходимых для выполнения тестирования. 1. Ожидаемые результаты и критерии приёмки: Описание ожидаемых выходных данных и критериев успешного завершения тестирования. Тест-план используется для структурирования и организации процесса тестирования, обеспечивая его эффективность и систематичность. Он также служит важным инструментом для коммуникации между членами команды и заинтересованными сторонами. Поддерживать тест-план необходимо в течение всего жизненного цикла проекта, внося необходимые изменения и обновления по мере необходимости. В большинстве проектов тест-план является неотъемлемой частью процесса разработки ПО, особенно в коммерческом и корпоративном программном обеспечении. Он помогает повысить уверенность в качестве продукта, минимизировать риски и обеспечить соответствие требованиям заказчика. :::note[Ссылки для изучения] 1. [Действительно ли вам нужен тест-план?](https://www.software-testing.ru/library/around-testing/processes/3704-do-you-really-need-a-test-plan) 2. [Содержание тест-плана. Artsiom Rusau QA Life, с 4:36](https://www.youtube.com/watch?v=LIpXj68VVCo&t=276s) ::: --- ## Какая разница между чеклистом и тест-кейсами? [#q-14bee738d69b81cc8ebbe7edca047ef1] Разница между чеклистом и тест-кейсами заключается в следующем: {/* prettier-ignore */} 1. Чеклисты: - Назначение: Используются для проверки выполнения задач или процедур. - Формат: Обычно представляют собой список шагов или критериев, которые необходимо выполнить или проверить. - Применение: Чеклисты помогают в систематической проверке выполнения действий или условий без детализации каждого шага. 1. Тест-кейсы: - Назначение: Используются для проверки функциональности или аспектов продукта. - Формат: Определяют конкретные шаги, ожидаемые результаты и предусловия для проведения тестирования. - Применение: Тест-кейсы используются для повторяемого тестирования функциональности, тестирования различных сценариев использования и проверки выполнения требований. Таким образом, чеклисты ориентированы на проверку выполнения процедур и не требуют подробного описания каждого шага, в то время как тест-кейсы используются для более детализированной проверки функциональности или конкретных аспектов продукта с заданными условиями и ожидаемыми результатами. :::note[Ссылки для изучения] 1. [Чеклисты или тест-кейсы?](https://habr.com/ru/articles/791334/#:~:text=%D0%A7%D0%B5%D0%BA-%D0%BB%D0%B8%D1%81%D1%82%20-%20%D1%8D%D1%82%D0%BE%20%D1%81%D0%BF%D0%B8%D1%81%D0%BE%D0%BA%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BE%D0%BA%2C,%D0%BA%D0%B0%D0%BA%20%D0%B2%D0%BC%D0%B5%D1%81%D1%82%D0%B5%2C%20%D1%82%D0%B0%D0%BA%20%D0%B8%20%D0%BE%D1%82%D0%B4%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE) 2. [Чек-лист и тест-кейс. Artsiom Rusau QA Life, с 8:10](https://www.youtube.com/watch?v=LIpXj68VVCo&t=490s) ::: --- ## Откуда брать ожидаемый результат, если требования неполны? [#q-transfer-0393] Сначала ищут наиболее авторитетный источник: утверждённый API-контракт, макет, стандарт, бизнес-правило или задокументированное прежнее поведение. Затем обращаются к владельцу продукта, аналитику или предметному эксперту. Найденное ожидание фиксируют в тесте со ссылкой на источник. Если источники расходятся, тестировщик не выбирает удобный вариант молча: оформляет вопрос или дефект требования и записывает временное предположение с ответственным. Текущее поведение системы может помочь обнаружить регрессию, но не автоматически становится правильным. Без согласованного oracle результат проверки следует пометить как неопределённый, а не «пройденный». :::note[Ссылки для изучения] 1. [Ожидаемый результат при неполном базисе: тестовый оракул — ISTQB, PDF, раздел 1.4.2](https://www.rstqb.org/ru/istqb-downloads.html?cid=13630&file=files%2Fcontent%2Frstqb%2Fdownloads%2FISTQB+Downloads%2FISTQB_CTAL-TA_Syllabus_v3.1.2_RU-1.pdf#page=19) ::: --- ## По каким признакам тест-кейс пригоден к выполнению? [#q-transfer-0394] У тест-кейса одна понятная цель и ссылка на требование или риск. Предусловия, роль, окружение и данные позволяют воспроизвести исходное состояние. Шаги содержат только необходимые действия и не зависят от результата другого теста. Ожидаемый результат наблюдаем и однозначен на значимых этапах, особенно после проверяемого действия. Другой специалист может выполнить кейс без устных подсказок и получить тот же вывод. При этом чрезмерная детализация каждого клика делает кейс хрупким. Уровень описания выбирают так, чтобы сохранить воспроизводимость и не дублировать очевидную инструкцию интерфейса. :::note[Ссылки для изучения] 1. [Воспроизводимый и проверяемый тест-кейс: цель, данные и ожидаемый результат — ISTQB, PDF, раздел 1.4.2](https://www.rstqb.org/ru/istqb-downloads.html?cid=13630&file=files%2Fcontent%2Frstqb%2Fdownloads%2FISTQB+Downloads%2FISTQB_CTAL-TA_Syllabus_v3.1.2_RU-1.pdf#page=18) 2. [Состав тест-кейса. Artsiom Rusau QA Life, с 11:16](https://www.youtube.com/watch?v=LIpXj68VVCo&t=676s) ::: --- ## Когда предусловие в тест-кейсе обязательно? [#q-transfer-0405] Предусловие обязательно, когда результат зависит от состояния системы, роли, данных, конфигурации или окружения, которые нельзя надёжно получить из самих шагов. Например, пользователь должен иметь определённое право, заказ быть в статусе `paid`, а feature flag включён. Предусловие описывает проверяемое исходное состояние или способ его создать, а не скрытую ссылку «подготовить как обычно». Общие настройки лучше вынести в фикстуру или документацию набора, чтобы не дублировать их в каждом кейсе. Если тест начинается из стандартного очевидного состояния и сам создаёт данные, отдельный блок предусловий может быть пустым. :::note[Ссылки для изучения] 1. [Предусловия теста: авторизация, данные и конфигурация окружения — документация ТестОпс](https://docs.qatools.ru/overview/test-cases/body/precondition/) 2. [Предусловия в тест-кейсе. Artsiom Rusau QA Life, с 11:31](https://www.youtube.com/watch?v=LIpXj68VVCo&t=691s) :::