QA Engineer

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

— Расписание проведения тестирования. Здесь определены временные рамки тестирования, включая начало и окончание каждого его цикла, а также ключевые даты, к которым должны быть достигнуты конкретные цели. Это помогает координировать усилия команды и обеспечивать соблюдение сроков.

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

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

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

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

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

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

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

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

Нежелание использовать тест-план в некоторых командах связано, во — первых, с тем, что текущий тренд в разработке программного обеспечения — это создавать небольшие обновления, которые проще тестировать. К тому же нередко команды разработки довольно маленькие: в них состоят 1–3 QA инженера. Из — за небольшого масштаба опытный QA вполне может держать этот план в голове и следовать ему.

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

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

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