Ризики у тестуванні ПЗ

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

Риски в тестировании ПО

Итак, во-первых: риски и проблемы зачастую сваливаются в одну кучу. Риск, по определению какой-то существующий или развивающийся фактор процесса, который обладает потенциально негативным воздействием на процесс и, как следствие, на его результат. Можно, конечно, дотянуть любую проблему до понятия риска, только зачем? В среднем, обычный тренинг по управлению рисками состоит всего на 20-25% из материалов про сам процесс управления рисками и описания типичных рисков, а в остальные 75% времени тренеры пытаются впихнуть под видом рисков описания процессных проблем под соусом «а ещё у вас может быть вот что…». Повторюсь — зачем?

Итак, разберёмся.

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

Проще говоря, чтобы чётко разграничить риск и проблему: риск это то, что может случиться и привести к негативным последствиям, а проблема, это то, что уже случилось или есть и мешает работать. И риск и проблема мешают или могут мешать работать, но способы работы с рисками и проблемами несколько разные: первые надо пытаться понять, найти и по возможности минимизировать их последствия до того как они «выстрелят», а с проблемами надо работать по факту — чинить или «тушить». Если отделить риски и проблемы, область управления рисками становится намного проще и понятнее.

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

Как работать с рисками

Алгоритм работы с рисками:

1. Выявление
2. Анализ и приоритезация
3. Планирование
4. Мониторинг и отчётность
5. Корректирование
6. Извлечение уроков

Или в виде вот такой картинки: http://pankratov.org.ua/it/risk-management-in-software-testing

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

Что, обычно, вызывает сложности на начальных этапах работы с рисками: собственно начать (внести эти активности в рабочие планы); понять, что работа с рисками не rocket science и что эти активности как и любые другие должны быть спланированы, обеспечены ресурсами (исполнителями), выполнены, а результаты должны быть проанализированы (что «выстрелило», что — нет, с чем мы справились успешно и т.д.).

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

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

Также не хотелось бы отвлекать внимание от основной темы этой статьи идеями про правильное целеполагание, но если в плане управления рисками будет написано «поговорить с шефом про ЗП ведущему тестеру» вместо «решить вопрос про повышение ЗП ведущему тестеру на 20%», то результатом выполнения такого таска в плане будет, скорее всего, не «повысили ЗП на 20%», а «поговорили с шефом про повышение…».

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

Типичные риски в тестировании ПО

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

Неполная оценка трудозатрат по проекту
Фредерик Брукс, в своей известной книге «Мифический человеко-месяц» отмечал, что именно этот риск является зачастую основной причиной невыполненных вовремя или вовсе провальных проектов.

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

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

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

Неполная оценка трудозатрат по тестированию

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

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

Как бороться: ревью и аудиты, формальные и «на бегу». В этом месте одна голова хорошо, а две — лучше.

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

Тест-план не привязан к плану проекта

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

Тестирование и разработка сидят на одном проектном ресурсе — на времени. Если планы двух направлений не связаны жестко (лучше всего на уровне одного общего плана работ по проекту, буквально линками между задачами в MS Project или любой другой подобной системе) или не синхронизированы на постоянной основе, существует вероятность или риск, что сдвиг планов разработки (который влияет на дату поставки версии в тестирование) не будет учтён в плане работ по тестированию, что приведёт к недостатку времени на тестирование и, как следствие, к незавершению этапа тестирования.

Почему планы тестирования и разработки ещё должны быть связаны жестко на уровне единого плана проекта: в зону ответственности менеджера проекта, при фиксированной длительности итерации кроме всего прочего относится управление объёмом (scope) итерации, для чего ему необходимо видеть работы по тестированию. Грубо говоря, в ограниченной по времени итерации задача ПМ-а выбрать такой объём функционала, который команда успеет и сделать и протестировать.

Если менеджеру проекта оценки трудозатрат по тестированию не нужны (см. «клиника»), задача менеджера по тестированию внести свои работы в план проекта и связать их с соотв. задачами по разработке. В такой схеме сдвинуть сроки тестирования крайне сложно — какая-то часть работ по тестированию просто будет наглядно вылазить за deadline в плане или на диаграммах.

Стратегия тестирования отсутствует или непринята группой разработки или заказчиком

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

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

Увольнение сотрудников

Риск увольнения ключевого или не очень ключевого сотрудника есть всегда.

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

Что делать. Держать «скамейку запасных» не всегда возможно по экономическим причинам. «Кормить лучше» помогает далеко не всегда, а иногда (в случае как раз с не ключевыми товарищами) это ещё и попросту невыгодно. Что тут можно сделать? Самое очевидное, что я вижу, это «договориться с соседями» — просто побеседовать с соседними отделами или проектами (у которых этот риск тоже есть) и договориться, что в случае такого события, они смогут хоть как-то (если это позволит специфика продукта и текущая загруженность) помочь вам людьми. Аналогично, будьте готовы помочь сами. Да-да, спасение утопающих — дело рук самих утопающих.

Остальные проблемы

Изменение даже зафиксированных требований или их приоритетов, зачастую относят к рискам, как к фактору, который повлияет на объём итерации и соотв. приведёт к пересмотру планов и возможно срыву сроков поставки версии. Я бы не называл эту часть проектной работы риском — это реальность, с которой надо работать как с проектным ограничением и стараться не дотягивать даже до состояния проблемы. Действенным путём является как раз ограничение объёмов итерации по срокам, когда любое изменение в требованиях приводит к выталкиванию какого-то другого кусочка работ (и девелопмент и тестирование) в следующую итерацию. Принудительно или административно «заставить» требования не меняться ещё ни у кого не получалось – бизнес меняется, требования меняются и если Заказчик готов платить не только за естественные изменения в требованиях, но и за свои «фантазии» или «неорганизованность» — это надо принять и уметь с этим жить.

Способы есть и они работают.

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

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

Риск игнорирования рисков

Один из рисков, который распространяется на все уровни управления рисками.
Нежелание принимать во внимание тот факт, что риски есть, что процесс (даже самый налаженный, выверенный, формализованный и контролируемый) может давать сбои, обычно приводит к чересчур оптимистичным планам, к конфликтам при их невыполнении, к необходимости перепланировать в «пожарном режиме» (что обычно приводит к просчётам и ещё больше нарушает нормальный ритм работ) и как результат к провалам.

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

Теперь, надеюсь, станет проще.

Источник публикации: http://pankratov.org.ua/it/risk-management-in-software-testing