Продолжаем цикл статей Пола Герарда о Лидерстве в тестировании.

Итак, что такое План?  

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

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

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

План — это не реальность; это модель реальности, требующая постоянного изменения. 

В этой статье я расскажу о каждом этапе планирования тестирования, включая: 

• Результаты 

• Процесс 

• Ресурсы 

• Ваша сеть поддержки 

• Оценки 

• Зависимости, риски и допущения 

• Коммуникация, обязательства и отчетность о прогрессе 

Но сначала давайте получим четкое представление о полезности плана. 

Зачем планировать? 

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

• Какие ресурсы требуются и когда.

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

• Навыки, необходимые для выполнения заданий.

• Инструменты и технологии, которые поддерживают план.

• Результаты и когда они будут доставлены.

• Затраты усилий и необходимых ресурсов.

• Процесс продвижения проекта/процесса по его этапам.

• Риски, которые угрожают доставке продукта. 

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

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

Стратегия определяет, как проект будет выполнен в принципе, план определяет и подтверждает, как проект будет выполнен на практике. 

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

Планирование — это путешествие, а не задача 

Цитируя бывшего президента США Дуайта Эйзенхауэра, “планирование — это все. План — это ничто.” Это чувство настолько важно, что оно повторяется почти в каждом контексте работы в системных проектах. Но что значит сказать, что план — это ничто? Какой смысл планировать, если в результате получается никчемный план? 

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

Структурированный и гибкий подход 

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

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

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

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

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

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

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

Планирование тестирования 

До сих пор мы рассматривали планирование проектов в целом и говорили о том, что это очень непрерывная деятельность. Теперь мы сосредоточимся конкретно на планировании тестирования в проектах. 

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

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

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

Каковы результаты тестирования? 

Что за вопрос! Конечно, это спецификации тестов, тесты, результаты и отчеты? Результаты, по сути, содержатся в документации, поэтому все, о чем нам нужно беспокоиться, — это оформить документы и поставить галочки в некоторых графах. 

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

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

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

Результат тестирования является свидетельством поведения системы, используемого заинтересованными сторонами для принятия решения. 

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

Ценность тестирования заключается в уровне уверенности заинтересованных сторон в принятии решений на основе результатов тестирования. 

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

Какими бы собранными и представленными они ни были, конечной задачей тестирования

является передача доказательств. 

Как 

Независимо от масштаба проекта или методологии, тестирование зависит от определенной серии мероприятий. Мы посмотрим на общий процесс глазами тестировщика (или команды), а затем рассмотрим некоторые из возникающих вариаций. 

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

Тестовые активности  

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

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

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

Логистика тестирования 

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

Ресурсы 

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

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

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

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

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

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

Ваша сеть поддержки 

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

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

Оценки 

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

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

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

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

• Требования подвержены ошибкам и неточны. 

• Люди более или менее компетентны, добросовестны и трудолюбивы. 

• Чем меньше объем работы, тем легче его оценить; разбивайте большие задачи на более мелкие блоки, где это возможно, и сводите оценки к более крупной задаче. 

• Оценка основана на опыте. Если у вас его нет, найдите, где опыт других людей имеет отношение к делу и может быть адаптирован. 

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

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

• Оцените наилучшую ситуацию, а затем наихудшую ситуацию. Хорошая оценка находится где-то посередине. 

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

Зависимости, риски и допущения 

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

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

Зависимости 

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

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

Риски 

Риск — это вероятность того, что ваш план провалится во время выполнения. Риск связан с такими вещами, как: 

• Ваши оценки: что может привести к тому, что ваши оценки окажутся неверными? Более сложная, дефектная, неполная или постоянно меняющаяся система — все это может повлиять на ваши оценки. 

• Люди недоступны, им не хватает опыта или навыков или они не полностью привержены вашей фазе проекта. Это могут быть члены команды или люди из вашей сети поддержки. 

• Инфраструктура, такая как тестовые среды, инструменты (или обучение использованию инструментов) или офисные помещения, недоступны, неправильно подготовлены или неисправны. 

• Предшествующие действия, не завершенные вовремя (или заброшенные, поставка частичной или бракованной продукции или вообще без доставки). 

Ответная реакция на риски 

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

• Допущение: риск считается достаточно низким, чтобы его игнорировать или рассматривать как несущественный. Но это находится на радаре и записывается как предположение (о доступности, полноте и т. д.) 

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

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

Коммуникация, обязательства и отчетность о прогрессе 

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

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

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

План — это соглашение между участниками. 

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

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

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