Wpływ testowania na jakość systemów informatycznych Zapewnienie jakości Jakość systemów informatycznych obecnie staje się coraz częściej dostrzeganym kryterium podczas wyboru dostawcy systemu przez kadrę kierowniczą. Niestety często problem jakości najczęściej dostrzega się dopiero, kiedy staje się ona stanowczo zbyt niska. Trzeba być świadomym, że jakość buduje się przez cały czas trwania projektu, w związku z tym należy przydzielić odpowiednie zasoby i budżet, żeby można było nią zarządzać. Niestety wysoka jakość kosztuje. Nie są to jednak wyrzucone pieniądze i należy potraktować je jako pewnego rodzaju polisę, która gwarantuje wykonanie lub wdrożenie systemu z należytą jakością. Środki przeznaczone na ten cel na ogół zwracają się z nawiązką, ponieważ usuwanie błędów jest znacznie bardziej kosztowne, a do tego zazwyczaj powoduje duże opóźnienia. Oczywiście założenie to zawsze powinno zostać poprzedzone głęboką analizą opłacalności, która pozwoli na właściwe zaplanowanie zakresu prac i alokacji odpowiednich zasobów. Zarządzanie jakością w projekcie ma na celu osiągnięcie odpowiedniego poziomu zadowolenia klienta. Na jakość składa się wiele czynników m.in. spełnienie wymagań formalnych, jak również prostota obsługi, czytelna dokumentacja czy też odpowiednio przygotowane szkolenia. Planując zarządzanie jakością należy wziąć pod uwagę szereg najróżniejszych czynników m.in. przepisy, normy, cel i zakres projektu, kryteria i warunki akceptacji oraz różnego typu wymagania funkcjonalne i pozafunkcjonalne. Unikanie typowych problemów Podczas realizacji projektów informatycznych często spotykane są podobne problemy związane z zapewnieniem odpowiedniej jakości. Najpoważniejsze spotykamy przy złożonych projektach, gdzie zazwyczaj o problemach dowiadujemy się zbyt późno. Wówczas mamy do czynienia z tzw. zjawiskiem gaszenia pożarów, co nie ma nic wspólnego z zarządzaniem pracami. Analizując przyczyny, można stwierdzić, że często powodem wyżej wymienionych problemów są źle zaplanowane prace testowe, gdzie sprawdzane są zbyt duże fragmenty oprogramowania, a do tego zbyt późno lub kontrola przeprowadzana jest w niewłaściwy sposób. Konsekwencją zazwyczaj jest przekroczony budżet projektu lub harmonogram prac, lub jedno i drugie. Niestety przekraczanie budżetu i
harmonogramu jest zmorą większości projektów informatycznych. Aby uniknąć takiej sytuacji większy naciski należy położyć na właściwe zorganizowanie pracy i zaangażowanie testowania od samego początku rozpoczęcia prac projektowych. Jakość, a testowanie W celu osiągnięcia zaplanowanej jakości na wstępnie konieczne jest zdefiniowanie strategii testowej, jaka będzie wykorzystywana na potrzeby realizowanego projektu. Dokument taki m.in. określa generalne zasady organizacji pracy i procedur z tym związanych. Ponadto definiuje związek prac testowych z wymaganiami projektowymi. Strategia testowa określa również, jakie narzędzia będę wykorzystywane podczas prowadzonych prac. Kolejnym ważnym krokiem jest zdefiniowanie procesu testowego, który z kolei określa sposób przeprowadzenia testów z wykorzystaniem analizy ryzyka i role. W celu właściwego zorganizowania pracy należy zaplanować, jakie narzędzia będą wykorzystywane do poszczególnych zadań oraz w jaki sposób musi zostać przygotowane środowisko testowe. Ważne jest również zdefiniowanie gdzie będą przechowywane dane testowe, logi testowe oraz jak będzie przebiegało zgłaszanie incydentów. W przypadku realizacji skomplikowanych systemów informatycznych często nie ma możliwości przetestowania wszystkich elementów systemu. Powodem jest zazwyczaj duża złożoność kodu oraz ograniczony czas i zasoby przeznaczone na testowanie. W związku z powyższym powinna zostać przyłożona odpowiednio duża waga do planowania testów, aby wykonywać w pierwszej kolejności testy, które mają największy wpływ na jakość. Przykładowo podstawą systemu finansowo-księgowego jest księgowanie dokumentów. Jeżeli ta funkcjonalność nie będzie działała prawidłowo reszta praktycznie jest bez znaczenia, ponieważ system nie nadaje się do zastosowania. Ponadto należy umiejętnie szacować prawdopodobieństwo możliwości wystąpienia defektu. Zatem planując testy w pierwszej kolejności powinno skoncentrować się na tych elementach, gdzie prawdopodobieństwo wystąpienia defektu jest największe oraz konsekwencje jego wystąpienia są najwyższe. Konsekwencje związane są z ryzykami, pełnią ważny wskaźnik pomagający w planowaniu testów, zatem głównym zadaniem testowania jest zmniejszenie prawdopodobieństwa wystąpienia ryzyka lub minimalizowanie jego skutków. Po zidentyfikowaniu zagrożeń ważne jest opracowanie czynności zaradczych. Dzięki takiemu podejściu możemy zarządzać pracami mając przygotowany plan działań na wypadek zmaterializowania się któregoś z ryzyk. Należy zwrócić również uwagę, że ryzyka nie mają charakteru stałego, co powoduje, że w trakcie postępu prac część ryzyk może zostać zdezaktualizowana, gdyż zagrożenie może minąć lub mogą pojawić się nowe ryzyka. Konieczne jest zatem okresowe monitorowanie ryzyk.
Należy również mieć na uwadze, że wszystkie przeprowadzone prace testowe powinny być dobrze udokumentowane. Wyróżniamy dwa generale rodzaje raportów: 1. raport statusu sporządzany okresowo, zawiera wyniki wykonanych testów, pozwalający na orientacje jaki jest bieżący status. 2. raport końcowy sporządzany na zakończenie danego etapu lub fazy testów. Dokumentacja z testów jest potwierdzeniem dbałości o jakość w trakcie procesu wytwarzania lub wdrażania oprogramowania. Raport z testów wiele mówi o sposobie realizacji prac oraz może być dowodem dołożenia należytej staranności wykonania prac. Sposoby przeprowadzania testów Testowanie jest skomplikowanym zagadnieniem, co potwierdzają liczne publikacje w fachowej prasie i literaturze, jednak w niniejszym artykule postaram się przybliżyć kilka podstawowych terminów, które nie zawsze są właściwie rozumiane. Generalnie możemy wyróżnić dwa podejścia do testowania: 1. Testy czarnoskrzynkowe - planujemy oraz przeprowadzamy testy nie mając wiedzy o budowie systemu. Na ogół ten typ testów ma na celu przeprowadzenie testów funkcjonalnych przez użytkowników posiadających wyłącznie wiedzę biznesową. 2. Testy białoskrzynkowe planujemy i przeprowadzamy testy z uwzględnieniem wiedzy o budowie wewnętrznej systemu. Ten typ testów może być wykorzystany np. do przetestowania zachowania systemu po wysłaniu odpowiedniego komunikatu z integrowanego systemu. Innym podziałem testowania, ze względu na technikę ich wykonywania wyróżniamy: 1. Testy statyczne polegają na uruchomieniu procesu testowania bez uruchamiania systemu. 2. Testy dynamiczne polegają na testowaniu zachowania uruchomionego systemu. Ze względu na różne zastosowanie testów możemy dokonać następującego podziału testów: 1. Testy integracyjne mają za zadanie przetestowanie spójności działania złożonego systemu zbudowanego z wielu modułów lub komponentów. Większość powszednie stosowanych systemów posiada dosyć złożoną budowę. Często również zamawiane systemy, które są integrowane z istniejącymi już innymi programami informatycznymi w organizacji. Z punktu widzenia firmy ważne jest, zatem zapewnienie odpowiedniego poziomu ich integracji. Zatem niebagatelną rolą jest opracowanie testów integracyjnych, które
potwierdzą właściwe połączenie i wyminę informacji pomiędzy poszczególnymi elementami. 2. Testy akceptacyjne mają za zadanie potwierdzenie zgodności realizacji systemu z zamówieniem. Najczęściej polegają one na opracowaniu przypadków testowych, a następnie zweryfikowaniu, czy działanie systemu jest zgodne z oczekiwaniami. Kluczem do właściwego przeprowadzenia tego typu testów są dobrze przygotowane przypadki testowe. Mogą one zostać opracowane zarówno na podstawie specyfikacji wymagań jak również możemy posiłkować się wiedzą ekspercką np. podczas opracowywania przypadków testowych dla systemu księgowo-finansowego bardzo przydatna może być księgowa, która posiada odpowiednią wiedzę merytoryczną pozwalającą na przetestowanie systemu w szczególnych przypadkach. Jedną z technik testowania jest testowane całych procesów w organizacji. Podejście procesowe pozwala stwierdzić, że nie tylko poszczególne funkcjonalności wykonywane są w systemie poprawnie, ale również całe procesy w organizacji są wspierane przez system zgodnie z założeniami. 3. Testy regresji mają za zadanie wyszukanie błędów, które powstały na skutek dokonanych modyfikacji np. po zaimplementowaniu nowych funkcjonalności lub przeprowadzeniu modyfikacji zgłoszonych incydentów, często pojawiają się błędy w funkcjonalnościach, które działają poprawnie, jednak przeprowadzona zmiana spowodowała błędne działanie danej funkcjonalności. 4. Testy wydajnościowe - pozwalają na zweryfikowanie działania aplikacji po zasymulowaniu odpowiedniego obciążenia systemu. Często zdarzają się przypadki, w których aplikacja, która przeszła pomyślnie testy integracyjne i akceptacyjne nie działa poprawnie podczas pracy w rzeczywistych warunkach. Powodem może być, albo niewłaściwie dobrany sprzęt, albo aplikacja może być napisana w nieodpowiedni sposób. W rękach inżynierów istnieje wiele norm, które standaryzują sposób przeprowadzania testów. Poniżej zamieszczę kilka wybranych: BS 7925-1 Software Testing Vocablary norma poświęcona testowaniu BS 7925-2 Software Component Testing norma poświęcona technikom i procesom w testowaniu komponentów IEEE 829, SW Test Documentation norma poświecona dokumentowaniu testowania IEEE 1012, Software Verification and Validation norma poświęcona weryfikacji i walidacji IEEE 1028 Software Reviews norma poświęcona definicjom różnych metod i technik przeglądów.
Wg normy IEEE 829 dokumentacja składa się z wielu poziomów. Całość spajana jest przez dokument, który opisuje generalne podejście do planowania i wykonywania testów. Zawiera m.in. takie informacje jak: cel testów, przedmiot testów, zasoby przydzielane do testowania oraz plan prac. Dokument związany jest m.in. dokumentami określającymi takie zagadnienia jak: plan testów akceptacyjnych, plan testów systemowych, plan testów komponentów oraz plan testów integracyjnych. Każdy z tych dokumentów określa zakres testów, procedury, zasoby oraz metodę testowania. Norma duży nacisk przykłada do dokumentowania sposobu wykonywania testów. Definiuje m.in. sposób dokumentowania niepoprawnych oraz nieoczekiwanych wyników testowania. Ponadto określa sposób dokumentowania przeprowadzonych testów akceptacyjnych, testów systemowych, testów komponentów oraz testów integracyjnych. Wszystkie najważniejsze informacje z dokumentów wymienionych powyżej zebrane są do jednego zbiorczego dokumentu. Kompetencje Zapewnienie wysokiej jakości nie jest zadaniem prostym polegającym na tzw. klikaniu w aplikacji i wymaga wysokich kwalifikacji oraz zazwyczaj specjalistycznego oprogramowania. Zbudowanie własnego zespołu z prawdziwego zdarzenia jest często kosztowne i czasochłonne, zatem wiele firm, które wdrażają w swojej organizacji systemy komputerowe poszukuje kompetencji wśród firm specjalizujących się w tego typu usługach. Wachlarz usług jest bardzo szeroki, począwszy od projektowania procesu testowego, zaprojektowaniu testów poprzez wykonanie i udokumentowanie testów, a skończywszy na audycie jakości. Podsumowanie Reasumując można stwierdzić, że testowanie ma na celu uzyskanie zaufania do systemu. Nie ma recepty mówiącej, jakie testy należy przeprowadzić, aby można było stwierdzić, że jakość systemu jest na odpowiednim poziomie, jest to indywidualny problem dotyczący konkretnie realizowanego projektu. Nie można stwierdzić, że wykonanie testów określonego typu testów np. testów akceptacyjnych gwarantuje otrzymanie systemu o wysokiej jakości, ponieważ jest to zależne od realizowanego projektu. Innym aspektem przemawiającym za zapewnieniem odpowiedniej jakości budowanego lub wdrażanego oprogramowania są koszty to się po prostu opłaca. Dużo taniej jest zadbać o odpowiednią jakość od samego początku realizowanego projektu, niż przedłużać jego realizację lub naprawiać konsekwencje błędnie działającego oprogramowania.
Studia doktoranckie na Politechnice Warszawskiej. Politechnika Warszawska, Informatyka - ukończone z wyróżnieniem studia wyższe. Pracownik Centralnego Ośrodka Informatyki Politechniki Warszawskiej. Zarządzanie projektami wg. standardu PMBOK GUIDE i PMI PMP Exam Preparation - IBM ISTQB Certified Tester, Fundation Level Kierowanie projektami zgodnie z PMI oraz Prince Zarządzanie jakością budowy systemów informatycznych Znajomość technologii JEE ( Java, JSP, JSF, Struts, Spring, Hibernate), Znajomość rozwiązań systemów klasy ERP (SAP, Oracle) Znajomość rozwiązań CRM m.in. Siebel Znajomość baz dancych Oracle, Microsoft SQL Server, PostgreSQL, MySQL, DB2 Doskonała znajomość UML Umiejętoność modelowania i optymalizacji procesów biznesowych. Opracowanie procedur i dokumentacji testów na potrzeby projektu realizowanego dla Europejskiego Funduszu Leasingowego Analiza wymagań na potrzeby wdroŝenia systemu CRM w sektorze ubezpieczeniowym i bankowym Udział w projektach integracyjnych Udział w audycie systemu informatycznego dla duŝej jednostki sektora publicznego Szkolenie Projektowanie przypadków testowych ETC Bettersoftware Szkolenie Zarządzanie testowaniem ETC Bettersoftware Konferencja Zarządzanie jakością systemów informatycznych oraz zarządzanie ryzykiem w trakcie realizacji projektu informatycznego Centrum Promocji Informatyki Wystąpienie za zgromadzeniu plenarnym Konferencji Rektorów Akademickich Szkół Polskich pt. Informatyzacja uczelni Krajowa Konferencja Naukowa Technologie Internetowe w zarządzaniu i biznesie referat pt. Mapowanie biznesowe od pomysłu do procesu