Автоматизированное тестирование как элемент жизненного цикла продукта

02.02.2017 |

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

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

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

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

Независимый IT-эксперт Виктор Солопов

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

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

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

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

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

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

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

Автор: Виктор Солопов, независимый IT-эксперт