Обновлен август 28, 2019
Тестирование широко применяется как часть разработки программного обеспечения с тех пор, как оно было разработано. Однако Business Intelligence (BI) медленнее внедряет тестирование в качестве интегрированной части разработки в программное обеспечение бизнес-аналитики, такое как IBM Cognos. Давайте выясним, почему бизнес-аналитика медленнее внедряет методы тестирования и последствия НЕ тестирование.
Почему организации не тестируют бизнес-аналитику…
- Временные ограничения. BI-проекты постоянно нуждаются в более быстром выполнении. Некоторые организации могут не осознавать, что самый простой этап сокращения времени - это тестирование.
- Ограничения бюджета. Считается, что тестирование слишком дорогое и не может выделить команду тестирования.
- Быстрее лучше. Это не обязательно «гибкий» подход, и он может только быстрее привести вас в неправильное место.
- Менталитет «сделай правильно с первого раза». Этот наивный подход настаивает на том, что наличие контроля качества должно уменьшить потребность в тестировании.
- Отсутствие собственности. Это похоже на предыдущий пункт. Считается, что «наши пользователи это протестируют». Такой подход может привести к недовольству пользователей и появлению большого количества обращений в службу поддержки.
- Отсутствие инструментов. Заблуждение, что у них нет подходящей технологии для тестирования.
- Непонимание тестирования. Например,
- Тестирование должно оценивать точность и достоверность данных, согласованность данных, своевременность данных, производительность доставки и простоту использования механизма доставки.
- Тестирование во время проекта бизнес-аналитики может включать регрессионное тестирование, модульное тестирование, дымовое тестирование, интеграционное тестирование, приемочное тестирование пользователя, специальное тестирование, стресс-тестирование / тестирование масштабируемости, тестирование производительности системы.
Каковы затраты на отказ от тестирования BI?
- Неэффективные конструкции. Плохая архитектура не может быть обнаружена, если тестирование игнорируется. Проблемы дизайна могут способствовать удобству использования, производительности, повторному использованию, а также обслуживанию и уходу.
- Проблемы с целостностью данных. Проблемы с повреждением или происхождением данных могут привести к недоверию к цифрам.
- Проблемы с проверкой данных. Решения, принятые на основании неверных данных, могут иметь разрушительные последствия для бизнеса. Нет ничего хуже, чем пытаться управлять метриками, основанными на неверной информации.
- Снижение принятия пользователями. Если числа неправильные или если приложение неудобно для пользователя, ваше сообщество пользователей просто не будет использовать ваше блестящее новое корпоративное программное обеспечение бизнес-аналитики.
- Повышенные затраты из-за отсутствия стандартизации.
- Увеличение затрат на устранение дефектов на более поздних этапах жизненного цикла разработки бизнес-аналитики.. Любые проблемы, обнаруженные за пределами этапа требований, будут стоить в геометрической прогрессии дороже, чем если бы они были обнаружены ранее.
Теперь, когда мы изложили, почему организации могут не проводить тестирование, и подводные камни, которые возникают, когда вы не тестируете бизнес-аналитику, давайте рассмотрим некоторые исследования по тестированию при разработке программного обеспечения.
Исследования показывают, что тестирование вашей платформы бизнес-аналитики экономит деньги!
Одно исследование 139 североамериканских компаний с численностью сотрудников от 250 до 10,000 5.2 человек сообщали о ежегодных затратах на отладку в размере от 22 до XNUMX млн долларов. Этот диапазон затрат отражает организации, которые не иметь автоматизированное модульное тестирование. Отдельно исследования IBM и Microsoft показали, что автоматизированное модульное тестирование, количество дефектов может быть уменьшено от 62% до 91%. Это означает, что затраты на отладку могут быть сокращены с 5–22 млн долларов до 0.5–8.4 млн долларов. Это огромная экономия!
Затраты на исправление ошибок быстро растут.
Документ об успешной тактике разработки программного обеспечения демонстрирует, что большинство ошибок совершается на ранних этапах цикла разработки и что чем дольше вы ждете, чтобы обнаружить и исправить, тем дороже вам придется исправить. Таким образом, не требуется ученого-ракетолога, чтобы сделать очевидный вывод о том, что чем раньше ошибки будут обнаружены и исправлены, тем лучше. Говоря о ракетостроении, так получилось, что НАСА опубликовало статью именно по этому поводу - «Повышение стоимости ошибок в течение жизненного цикла проекта».
Интуитивно понятно, что затраты на исправление ошибок возрастают по мере продвижения жизненного цикла разработки. Исследование НАСА было проведено, чтобы определить, насколько быстро увеличивается относительная стоимость исправления обнаруженных ошибок. В этом исследовании использовались три подхода к определению относительных затрат: метод восходящей стоимости, метод разбивки общих затрат и нисходящий гипотетический метод проекта. Подходы и результаты, описанные в этой статье, предполагают разработку аппаратно-программной системы, имеющей проектные характеристики, аналогичные тем, которые использовались при разработке большого сложного космического корабля, военного самолета или небольшого спутника связи. Результаты показывают степень роста затрат, поскольку ошибки обнаруживаются и исправляются на более поздних этапах жизненного цикла проекта. Это исследование является репрезентативным для других проведенных исследований.
На приведенной выше диаграмме исследования TRW, IBM, GTE, Bell Labs, TDC и других показывают стоимость исправления ошибок на различных этапах разработки:
- Стоимость исправления ошибки, обнаруженной на этапе требований, определяется как 1 блок
- Стоимость исправления этой ошибки, если она будет обнаружена на этапе проектирования, составляет двойной который
- На этапе кода и отладки стоимость исправления ошибки составляет 3 единиц
- На этапе модульного тестирования и интеграции стоимость исправления ошибки становится равной 5
- На этапе тестирования системы Стоимость исправления ошибки возрастает до 20
- И как только система перейдет в фазу эксплуатации, относительная стоимость исправления ошибки возросла до 98, что почти в 100 раз превышает стоимость исправления ошибки, если она обнаружена на этапе требований.!
Суть в том, что ремонт дефектов обходится гораздо дороже, если их не выявить на ранней стадии.
Выводы
Были проведены значительные исследования, демонстрирующие ценность раннего и непрерывного тестирования при разработке программного обеспечения. Мы, члены сообщества бизнес-аналитиков, можем учиться у наших друзей в разработке программного обеспечения. Несмотря на то, что большинство официальных исследований было проведено в отношении разработки программного обеспечения, аналогичные выводы можно сделать и в отношении разработки бизнес-аналитики. Ценность тестирования бесспорна, но многие организации не спешили использовать преимущества формального тестирования своей среды бизнес-аналитики и интегрировать тестирование в свои процессы разработки бизнес-аналитики. Стоимость не тестирование реально. Риски, связанные с не тестирование реально.
Хотите увидеть в действии автоматическое тестирование Cognos? Смотрите видео в нашем плейлисте от нажав здесь!
