Оновлено серпень 28, 2019
Тестування отримало широке поширення як частина розробки програмного забезпечення з тих пір, як було розроблено програмне забезпечення. Однак Business Intelligence (BI) повільніше впроваджував тестування як невід'ємну частину розробки програмного забезпечення для бізнес -аналітиків, такого як IBM Cognos. Давайте дослідимо, чому BI повільніше впроваджує практику тестування та наслідки НЕ тестування.
Чому організації не тестують BI ...
- Часові обмеження. Проекти БІ зазнають постійного тиску на швидше реалізацію. Деякі організації можуть не усвідомлювати, що найпростіший етап скорочення часу - це тестування.
- Бюджетні обмеження. Думають, що тестування надто дороге і не може виділити команду з тестування.
- Швидше - краще. Це не обов’язково “спритний” підхід, і він може швидше потрапити в неправильне місце.
- Менталітет "просто зроби це правильно з першого разу". Цей наївний підхід наполягає на тому, що наявність контролю якості повинна зменшити потребу в тестуванні.
- Відсутність власності. Це схоже на попередню форму. Думають, що "наші користувачі це перевірять". Такий підхід може призвести до незадоволених користувачів та великої кількості квитків у службу підтримки.
- Відсутність інструментів. Помилкова думка, що вони не мають відповідної технології для тестування.
- Нерозуміння тестування. Наприклад,
- Тестування має оцінювати точність та достовірність даних, узгодженість даних, своєчасність даних, ефективність доставки та простоту використання механізму доставки.
- Тестування під час проекту BI може включати регресійне тестування, модульне тестування, тестування диму, інтеграційне тестування, тестування прийнятності користувачами, спеціальне тестування, тестування на стрес/масштабованість, тестування продуктивності системи.
Яка вартість НЕ тестування BI?
- Неефективні конструкції. Якщо ігнорувати тестування, погана архітектура може бути не виявлена. Проблеми з дизайном можуть вплинути на зручність використання, продуктивність, повторне використання, а також технічне обслуговування та утримання.
- Проблеми цілісності даних. Пошкодження даних або проблеми з походженням даних можуть призвести до відсутності довіри до цифр.
- Проблеми перевірки даних. Рішення щодо невірних даних можуть бути руйнівними для бізнесу. Немає нічого гіршого, ніж намагатися керувати за допомогою показників, заснованих на неправильній інформації.
- Зменшення прийняття користувачів. Якщо цифри неправильні, або якщо програма не є зручною для користувачів, ваша спільнота користувачів просто не буде використовувати ваше блискуче нове програмне забезпечення корпоративної BI.
- Збільшення витрат через відсутність стандартизації.
- Збільшення витрат на усунення дефектів на пізніх стадіях життєвого циклу розробки BI. Будь -які проблеми, виявлені поза фазою вимог, будуть коштувати експоненціально дорожче, ніж якщо були виявлені раніше.
Тепер, коли ми виклали, чому організації можуть не проводити тестування, і підводні камені, які виникають, коли ви не тестуєте BI, давайте розглянемо деякі дослідження з тестування при розробці програмного забезпечення.
Дослідження показують, що тестування вашої платформи BI економить гроші!
Одне дослідження 139 північноамериканських компаній розміром від 250 до 10,000 5.2 співробітників, щорічні витрати на налагодження складали від 22 до XNUMX мільйонів доларів. Цей діапазон витрат відображає організації, які НЕ мають автоматизоване модульне тестування. Окремо дослідження IBM та Microsoft виявили це з на місці автоматизованого одиничного тестування, кількість дефектів можна зменшити на 62% до 91%. Це означає, що долари, витрачені на налагодження, можна зменшити з діапазону від 5 до 22 мільйонів доларів до діапазону від 0.5 до 8.4 мільйонів доларів. Це величезна економія!
Швидка ескалація витрат на виправлення помилок.
Документ про успішну тактику розробки програмного забезпечення демонструє, що більшість помилок допущено на початку циклу розробки і що чим довше ви чекаєте на виявлення та виправлення, тим дорожче вам виправити. Отже, ракетному вченому не потрібно робити очевидний висновок, що чим швидше помилки будуть виявлені та виправлені, тим краще. Якщо говорити про ракетну науку, так сталося, що NASA опублікувало статтю саме про це - "Ескалація витрат на помилки через життєвий цикл проекту".
Інтуїтивно зрозуміло, що витрати на виправлення помилок зростають у міру проходження життєвого циклу розробки. Дослідження NASA було проведено, щоб визначити, наскільки швидко прогресує відносна вартість виправлення виявлених помилок. У цьому дослідженні використовувалися три підходи для визначення відносних витрат: метод витрат знизу вгору, метод розподілу загальних витрат та метод гіпотетичного проекту зверху вниз. Підходи та результати, описані в цій роботі, передбачають розробку апаратно -програмної системи, що має проектні характеристики, подібні до тих, що використовуються при розробці великого складного космічного корабля, військового літака або невеликого супутника зв’язку. Результати показують ступінь зростання витрат, оскільки помилки виявляються та виправляються на пізніх та пізніх фазах життєвого циклу проекту. Це дослідження є репрезентативним для інших досліджень, які були проведені.
З таблиці вище дослідження TRW, IBM, GTE, Bell Labs, TDC та інших показує вартість виправлення помилок на різних етапах розробки:
- Вартість виправлення помилки, виявленої на етапі вимог, визначається як 1 блок
- Витрати на виправлення цієї помилки, якщо вони будуть виявлені на етапі проектування, складають подвійний Що
- На етапі коду та налагодження вартість виправлення помилки становить блоки 3
- На етапі одиничного тестування та інтеграції вартість виправлення помилки стає більшою 5
- На фазі випробування систем, вартість виправлення помилки зростає до 20
- І як тільки система буде на етапі роботи, відносна вартість виправлення помилки зросла до 98, що майже в 100 разів перевищує вартість виправлення помилки, якщо вона виявляється на етапі вимог!
Суть в тому, що виправлення дефектів набагато дорожче, якщо вони не виявлені завчасно.
Висновки
Було проведено значне дослідження, яке демонструє цінність раннього та безперервного тестування при розробці програмного забезпечення. Ми, у спільноті BI, можемо вчитися у наших друзів у розробці програмного забезпечення. Незважаючи на те, що більшість офіційних досліджень були проведені стосовно розробки програмного забезпечення, подібні висновки можна зробити і щодо розробки BI. Цінність тестування незаперечна, але багато організацій повільніше скористалися перевагами офіційного тестування свого середовища BI та інтегрували тестування у свої процеси розробки BI. Витрати на НЕ тестування справжнє. Ризики, пов'язані з НЕ тестування справжнє.
Хочете побачити деяке автоматизоване тестування Cognos у дії? Перегляньте відео у нашому списку відтворення до натиснувши тут!
