Создание программного обеспечения невероятно сложный процесс. Но именно это привлекает многих разработчиков программных приложений: они наслаждаются возможностью изучить детали, синтаксис, нюансы, форму и структуру платформ кодирования, которые позволяют им создавать функциональные возможности программных приложений, которые пользователи в конечном итоге найдут полезными, получат удовольствие и, возможно, даже иногда будут восхищаться.
Но кодирование на самом деле настолько сложно, что у нас на планете недостаточно разработчиков программного обеспечения, чтобы удовлетворить кажущийся ненасытным спрос на приложения (и все пользовательские оптимизации и настройки), необходимые в типичном современном ИТ-стеке предприятия.
Low-code / No-code
В частности, за последние пять лет появилось множество программных low-code / no-code инструментов, которые помогают попытаться обойти некоторые проблемы, с которыми сталкиваются разработчики. Если говорить, в частности, о low-code, то это инструменты, которые предоставляют шаблоны, справочные архитектуры и различные типы (часто одобренные лучшими практиками) ярлыков для инженеров-программистов, которые можно использовать на стыке программирования и разработки.
Low-code по-прежнему требует много кодирования, и lower-Code, возможно, было бы более точным обозначением. Еще проще - это no-code, платформы, предназначенные для абстрагирования от сложности кода и предоставления тем, кто часто не является техническим бизнес-пользователем, возможности использовать графические drag-and-drop интерфейсы для создания функциональных возможностей программного обеспечения. Оба метода полезны, но оба могут быть частично или потенциально ответственны за разработку несовершенного программного обеспечения, если приложения, для создания которых они используются, а) недолжным образом контролируются организациями, использующими их, б) недолжным образом защищены и заблокированы в соответствии с руководящими принципами компании и корпоративного соответствия и в) недолжным образом протестированы, прежде чем они станут частью живой рабочей структуры ИТ-стека организации.
Отслеживание и тестирование
Например, элемент тестирования — то, что не дает компании Copado спать по ночам. Фирма представляет собой платформу DevOps (разработчик + операции), которая работает для поддержки корпоративного программного обеспечения, особенно в области развертывания Salesforce.
Компания проводит ежегодный анализ среди разработчиков и специалистов по обеспечению качества, чтобы собрать сотни точек данных и попытаться дать некоторое представление о методах тестирования программного обеспечения в тех компаниях, которые считаются "самыми сложными компаниями", использующими Salesforce.
По словам Пэта Маккуина, старшего вице-президента по развитию Copado, тестирование в Salesforce становится все более важным, поскольку задействована экосистема пользовательских приложений, управляемых пакетов из AppExchange и интеграций. Организациям приходится не только приспосабливаться к изменениям, когда речь заходит о развертывании Salesforce, но и отслеживать интеграцию с другими системами, имеющими собственные циклы выпуска.
“С этими быстрыми инновациями возникает необходимость в масштабируемом комплексном тестировании. Недавний отчет Forrester подтверждает, что организации, использующие low-code платформы, такие как low-code инструменты Salesforce, не могут позволить себе игнорировать автоматическое тестирование”, - настаивают Маккуин и команда в заявлении для прессы.
Рассматриваемая здесь проблема может быть связана с тем фактом, что так много компаний все еще используют традиционные методы тестирования - такие как ручное тестирование или решения на основе сценариев, - когда они могли бы подключиться к новой эре автономного управления системами, которые предлагают более автоматизированный подход к тестированию.
Время окупаемости “технического долга”
Следствием этого "надзора за автоматизацией" (пока еще не является де-факто отраслевым термином, но скоро это может произойти) является то, что качество выпусков программного обеспечения страдает, поскольку недостаточно времени для тестирования изменений перед развертыванием. Дефекты, обнаруженные позже в цикле выпуска, почти всегда дороже исправлять из-за “технического долга”, возникшего в результате быстрого развертывания, который необходимо "вернуть" во время исправления кода, как и любой финансовый долг, требующий возврата.
“В мире, где на первый план выходит использование no-code/low-code платформ, компании явно приходят к выводу, что автоматизированное тестирование - лучший способ двигаться быстро и не ломать вещи”, - сказал Маккуин из Copado. “Команды, которые уделяют приоритетное внимание своей стратегии тестирования, превосходят тех, кто этого не делает. Инвестиции в автоматизированное тестирование обеспечивают гибкость бизнеса, что приводит к долгосрочному коммерческому успеху на конкурентном рынке".
Главный посыл заключается в том, что ручное тестирование не является масштабируемым и дорогостоящим. Это означает, что дефекты в производстве программного обеспечения могут оказать огромное финансовое воздействие на компании. Согласно собственному исследованию, 41% организаций не имеют достаточно времени, чтобы полностью протестировать все изменения перед выпуском из-за нехватки времени, что вынуждает команды сокращать объем тестирования. До 92% фирм ежегодно сталкиваются с производственными проблемами (выявленными дефектами) из-за неадекватного тестирования.
Стоимость отказа от автоматизированного тестирования значительно увеличивает частоту производственных сбоев, несмотря на увеличение инвестиций в команду тестирования. Команды, использующие автоматизированное тестирование, сталкивались с менее чем вдвое меньшим количеством производственных сбоев в год в результате выпусков (в среднем 3 в год вместо 7).
Команды, использующие автоматизированное тестирование, выпускают релизы на 50% чаще, чем команды, использующие ручное тестирование (в среднем 34 раза в год по сравнению с 22 разами в год). Команды, использующие автоматическое тестирование, имели на 50% больше шансов выполнить все свои планы тестирования для каждого выпуска (67% команд, использующих автоматическое тестирование, сообщили о завершении всех своих тестов для каждого выпуска по сравнению только с 45% команд, полагающихся на ручное тестирование).
Автор: Адриан Бриджуотер “Я отслеживаю разработку корпоративных программных приложений и управление данными.”
Источник: Forbes
