Действительно ли вам нужен тест-план?

Недавно я наткнулся на твит Бена Доуэна (известного как Full Snack Tester, основателя сайта Tester Of The Day). В твите был опрос:

Как вы относитесь к тест-планам?

• необходимы всегда (21,3%)
• опциональны, но полезны (50%)
• пустая трата времени (15,7%)
• просто покажите мне результаты опроса (13%)

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

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

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

Проблема с тест-планами

На первый взгляд тест-планы кажутся отличной идеей. К примеру, вот определение тест-плана из Википедии:

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

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

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

Возможно, главная проблема с тест-планами – это скорость их рассинхронизации с проектом. Иногда план устаревает, как только команда его дописала. Это особенно очевидно в agile-командах, где проект меняется и трансформируется еженедельно. Если у вас нет специального человека, занятого только поддержкой и обновлением тест-плана, то у вас на руках окажется документ, не отражающий реальное положение дел в проекте.

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

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

Кому выгоден тест-план?

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

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

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

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

Кому не нужен тест-план?

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

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

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

Вам все равно нужно следить за тестированием

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

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

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

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

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

Заключение

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

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

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

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

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

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

Оригинал статьи: https://dev-tester.com/do-you-really-need-a-test-plan/

Перевод статьи: https://software-testing.ru/library/around-testing/processes/3704-do-you-really-need-a-test-plan