Тестирование для предотвращения нежелательных последствий

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

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

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

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

В теории, все логично, но на практике все может пойти криво на любой стадии работы. Есть множество примеров ужасных сбоев в коммуникации, когда список требований вырабатывается и подписывается бизнес-специалистами, даже когда бизнес и ИТ привлеченные специалисты высококвалифицированные люди. Почему так? Потому что эти две группы людей часто говорят на разных языках, у них свой жаргон, предположения, образы мышления, и часто, они игнорируют идеи другой стороны. Следующие проблемы возникают дальше, когда ведущие проект ИТ специалисты озвучивают команде разработчиков требования к будущему софту. Группа бизнесменов часто не понимает всего наследия языков программирования и баз данных (Java, C++, SAP, Oracle – как примеры) и между ними появляется еще большее непонимание.

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

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

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

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

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

Но те CIO, которые все еще упрямятся, и кто еще не понял необходимость рассматривать тестирование, как наважнейший процесс, должны проснуться и еще раз подумать – до того, как придется пожинать плоды своих сомнений.  И не забывайте – исправить ошибку после производства в 10-250 раз дороже, чем исправить ее до выпуска продукта.

Подготовлено НП «СОДЕЙСТВИЕ»