Zaktualizowano sierpień 28, 2019
Testowanie jest szeroko stosowane jako część rozwoju oprogramowania od samego początku rozwoju oprogramowania. Jednak Business Intelligence (BI) wolniej przyjmuje testowanie jako integralną część rozwoju oprogramowania BI, takiego jak IBM Cognos. Przyjrzyjmy się, dlaczego BI wolniej przyjmuje praktyki testowe i jakie są konsekwencje NIE testowanie.
Dlaczego organizacje nie testują BI…
- Ograniczenia czasowe. Projekty BI znajdują się pod stałą presją szybszej realizacji. Niektóre organizacje mogą nie zdawać sobie sprawy, że najłatwiejszą fazą na skrócenie czasu jest testowanie.
- Ograniczenia budżetowe. Myślenie jest takie, że testowanie jest zbyt drogie i nie może poświęcić zespołu testowego.
- Szybciej tym lepiej. Niekoniecznie jest to podejście „zwinne” i może tylko szybciej zaprowadzić Cię w niewłaściwe miejsce.
- Mentalność „zrób to dobrze za pierwszym razem”. To naiwne podejście podkreśla, że obecność kontroli jakości powinna zmniejszyć potrzebę testowania.
- Brak własności. To jest podobne do poprzedniego punktu. Myślenie jest takie, że „nasi użytkownicy to przetestują”. Takie podejście może prowadzić do niezadowolonych użytkowników i wielu zgłoszeń do pomocy technicznej.
- Brak narzędzi. Błędne przekonanie, że nie mają odpowiedniej technologii do testowania.
- Brak zrozumienia testowania. Na przykład,
- Testowanie powinno oceniać dokładność i ważność danych, spójność danych, aktualność danych, wydajność dostarczania i łatwość użycia mechanizmu dostarczania.
- Testowanie w ramach projektu BI może obejmować testy regresyjne, testy jednostkowe, testy dymne, testy integracyjne, testy akceptacyjne użytkownika, testy ad hoc, testy warunków skrajnych/skalowalności, testy wydajności systemu.
Jakie są koszty NIETESTOWANIA BI?
- Nieefektywne projekty. Słaba architektura może nie zostać wykryta, jeśli testowanie zostanie zignorowane. Problemy projektowe mogą przyczynić się do użyteczności, wydajności, ponownego użycia, a także konserwacji i utrzymania.
- Problemy z integralnością danych. Uszkodzenie danych lub wyzwania związane z pochodzeniem danych mogą prowadzić do braku zaufania do liczb.
- Problemy z walidacją danych. Decyzje podejmowane na podstawie złych danych mogą być katastrofalne dla firmy. Nie ma nic gorszego niż próba zarządzania za pomocą metryk opartych na nieprawidłowych informacjach.
- Zmniejszona adopcja użytkowników. Jeśli liczby się nie zgadzają lub jeśli aplikacja nie jest przyjazna dla użytkownika, społeczność użytkowników po prostu nie będzie korzystać z nowego, błyszczącego oprogramowania BI dla przedsiębiorstw.
- Wzrost kosztów z powodu braku standaryzacji.
- Zwiększone koszty naprawy usterek na późniejszych etapach cyklu życia rozwoju BI. Wszelkie problemy wykryte poza fazą wymagań będą kosztować wykładniczo więcej niż w przypadku wykrycia wcześniej.
Teraz, gdy wyjaśniliśmy, dlaczego organizacje mogą nie testować i jakie pułapki pojawiają się, gdy nie testujesz BI, przyjrzyjmy się niektórym badaniom dotyczącym testowania w tworzeniu oprogramowania.
Badania pokazują, że testowanie platformy BI pozwala zaoszczędzić pieniądze!
Jedno badanie 139 firm północnoamerykańskich zatrudniający od 250 do 10,000 5.2 pracowników, zgłosił roczne koszty debugowania w wysokości od 22 mln do XNUMX mln USD. Ten zakres kosztów odzwierciedla organizacje, które: nie mieć wdrożone zautomatyzowane testy jednostkowe. Oddzielnie badania przeprowadzone przez IBM i Microsoft wykazały, że w wdrożone zautomatyzowane testy jednostkowe, liczba defektów może zostać zmniejszona o 62% do 91%. Oznacza to, że dolary wydane na debugowanie mogą zostać zredukowane z przedziału 5–22 mln USD do zakresu od 0.5 mln USD do 8.4 mln USD. To ogromne oszczędności!
Koszty szybkiego naprawiania błędów rosną.
Artykuł na temat skutecznych taktyk tworzenia oprogramowania pokazuje, że większość błędów powstaje na wczesnym etapie cyklu rozwoju i im dłużej czekasz na wykrycie i poprawienie, tym wyższe koszty naprawy. Nie trzeba więc naukowca od rakiet, aby wyciągnąć oczywisty wniosek, że im szybciej błędy zostaną wykryte i naprawione, tym lepiej. Mówiąc o nauce rakietowej, tak się składa, że NASA opublikowała artykuł na ten temat – „Eskalacja kosztów błędów w cyklu życia projektu”.
Intuicyjne jest, że koszty naprawy błędów rosną wraz z postępem cyklu rozwoju. Przeprowadzono badanie NASA, aby określić, jak szybko postępuje względny koszt naprawy wykrytych błędów. W badaniu wykorzystano trzy podejścia do określenia kosztów względnych: metodę kosztów od dołu do góry, metodę podziału kosztów całkowitych oraz metodę odgórnego projektu hipotetycznego. Podejścia i wyniki opisane w tym artykule zakładają opracowanie systemu sprzętowo-programowego o charakterystyce projektowej podobnej do tej, która została zastosowana przy opracowywaniu dużego, złożonego statku kosmicznego, samolotu wojskowego lub małego satelity komunikacyjnego. Wyniki pokazują, w jakim stopniu koszty rosną, ponieważ błędy są wykrywane i naprawiane na kolejnych i późniejszych etapach cyklu życia projektu. Niniejsze badanie jest reprezentatywne dla innych przeprowadzonych badań.
Z powyższego wykresu, badania TRW, IBM, GTE, Bell Labs, TDC i innych pokazują koszt naprawy błędów w różnych fazach rozwoju:
- Koszt naprawy błędu wykrytego w fazie wymagań określa się jako Jednostka 1
- Koszt naprawienia tego błędu, jeśli zostanie on znaleziony w fazie projektowania, wynosi Podwójna że
- W fazie kodu i debugowania koszt naprawy błędu wynosi jednostki 3
- W fazie testów jednostkowych i integracji koszt naprawy błędu staje się 5
- W fazie testów systemów, koszt naprawy błędu skacze do 20
- A gdy system jest w fazie eksploatacji, względny koszt naprawienia błędu wzrósł do 98, prawie 100 razy więcej niż koszt naprawienia błędu, jeśli zostanie znaleziony w fazie wymagań!
Najważniejsze jest to, że naprawa usterek jest znacznie bardziej kosztowna, jeśli nie zostaną wykryte wcześnie.
wnioski
Przeprowadzono znaczące badania, które pokazują wartość wczesnych i ciągłych testów w tworzeniu oprogramowania. My, w społeczności BI, możemy uczyć się od naszych przyjaciół w tworzeniu oprogramowania. Chociaż przeprowadzono większość formalnych badań związanych z tworzeniem oprogramowania, podobne wnioski można wyciągnąć na temat rozwoju BI. Wartość testowania jest bezdyskusyjna, ale wiele organizacji wolniej korzysta z formalnego testowania środowiska BI i integruje testowanie z procesami rozwoju BI. Koszty nie testy są prawdziwe. Zagrożenia związane z nie testy są prawdziwe.
Chcesz zobaczyć w akcji automatyczne testy Cognos? Obejrzyj filmy na naszej playliście przez klikając tutaj!
