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

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

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

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

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

• Какие результаты должны получить и в какой срок.

• Стоимость ресурсов.

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

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

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

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

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

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

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

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

Структурированное vs гибкое планирование

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

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

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

Часто незапланированные события воспринимаются просто как шум и не привлекают особого внимания. Однако впоследствии некоторые из этих мелких сбоев превращаются в серьезные проблемы. Одна из проблем проектов с каскадной (waterfall) моделью разработки заключается в том, что эта постоянная корректировка воспринимается как обременительная, а любые изменения рассматриваются как ненужная возня. Проекты часто идут наперекосяк, а команда верит, что «как-нибудь разрулим и всё будет хорошо». Но так бывает редко, и об этом уже не раз говорилось:

«Как проект отстает на год? Сначала он отстает на один день» (Фред Брукс).

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

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

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

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

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

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

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

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

Давайте рассмотрим некоторые из основных элементов плана тестирования.

Результаты тестирования

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

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

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

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

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

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

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

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

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

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

Как

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

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

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

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

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

Подготовительные работы

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

Ресурсы

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

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

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

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

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

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

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

Оценка

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

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

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

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

• Требования не исключают ошибок и могут быть неточны.

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

• Чем меньше задача, тем легче ее оценить; разбивайте большие задачи на более мелкие.

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

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

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

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

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

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

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

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

Зависимости

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

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

Риски

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

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

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

• Отсутствие инфраструктуры, такой как тестовые среды, инструменты (или обучение работе с ними) или офисное пространство, их неправильная подготовка или дефекты.

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

Ответные меры

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

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

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

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

Коммуникации, коммитменты и отчетность о проделанной работе

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

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

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

План представляет собой договор между участниками.

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

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

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

Поэтому, чтобы получить ответы на эти вопросы, нужно использовать оба показателя: code coverage и test coverage.

Подробнее об оценке эффективности тестовой стратегии с помощью тестового покрытия поговорим на открытом уроке 21 сентября. Встреча пройдет в рамках курса "QA Lead". Присоединяйтесь