Zarządzanie jakością i testowanie IT - fakty i mity

Wokół zarządzania jakością i testowania narosło wiele błędnych przekonań, co prowadzi do nieporozumień zarówno jeśli chodzi o zakres obowiązków jak i umiejętności wymaganych od osób zajmujących się tymi zagadnieniami.


Zarządzanie jakością

Pierwszym pytaniem jaki powinno nasunąć się przy określeniu funkcji osoby zajmującej się zarządzaniem jakością jest pytania czym tak naprawdę jest jakość. Tak przez analogię: często słyszymy pytanie „czy jutro będzie pogoda” w znaczeniu „czy jutro będzie słoneczna pogoda”. Podobnie jest z jakością: jakość nie jest wyznacznikiem, że produkt jest dobry, czy tez bardzo dobry - jakość (za Słownikiem języka polskiego wydawnictwa PWN) to „właściwość, rodzaj, gatunek, wartość; zespół cech stanowiących o tym, że dany przedmiot jest tym przedmiotem, a nie innym” - zatem jakość to nie jest poprawność, niezawodność czy inne kryterium. Jakość to miara tych kryteriów. Zarządzanie jakością nie jest zatem wyszukiwaniem błędów, tylko „wytworzeniem przekonania, że produkt spełnia przypisywane mu kryteria”. Przekonanie to najczęściej należy wytworzyć u klienta, jednak aby je u niego wytworzyć trzeba samodzielnie zbadać, czy rzeczywiście produkt jest taki, jaki zakładamy. Wcale zresztą nasz produkt nie musi być wysokiej jakości.



Niejednokrotnie jako klienci mamy wybór pomiędzy produktami o różnej jakości od niskiej, po wysoką - często świadomie decydujemy się na produkt o potencjalnie niskiej jakości (kupię to urządzenie za niewielkie pieniądze, bo będę z niego korzystać tylko przez miesiąc - jak się po miesiącu uszkodzi, wówczas bez żalu się z nim pożegnam). Taka jest też rola systemów zarządzania jakością z najsłynniejszym chyba ISO 9001 na czele. To, że producent danego produktu chwali się, że ma certyfikowany system zarządzania jakością nie oznacza przecież, że jego produkty są „najwyższej” jakości. Możemy oczywiście podejrzewać, że skoro wdrożył niemałym wysiłkiem i kosztem taki system, to jego celem jest dążenie do posiadania w ofercie produktów o jak najwyższej jakości, ale to są tylko podejrzenia. Często jest przecież tak, że celem wdrożenia takiego systemu jest utrzymanie stałego poziomu jakości, choć niekoniecznie musi być to „najwyższa” jakość. Jeśli ktoś nie wierzy, może osobiście rozejrzeć się wśród produktów spożywczych na przykład: jest wielu producentów, którzy mają certyfikowane systemy zarządzania jakością, a ich produkty na pewno nie należą to tych najlepszych (pod względem np. smaku, czy użytych składników) na rynku. Osoba zarządzająca jakością raczej szuka błędów w procesie wytwórczym (w naszym przypadku oprogramowania), a nie w finalnym produkcie. Celem działalności takiej osoby jest pełna identyfikacja procesów zachodzących podczas wytwarzania oprogramowania. Dopiero taka pełna identyfikacja pozwala na wyszukanie etapów, które powodują, że jakość nie jest zgodna z oczekiwaniami.

W przypadku projektów programistycznych jest to o tyle trudne, że proces wytwarzania oprogramowania pozwala na bardzo dużą swobodę jego uczestników. Zaryzykuję twierdzenie, że żadna inna branża nie pozwala na porównywalnie dużą swobodę. Projekty informatyczne często porównuje się do projektów z branży budowlanej - tak samo jak budynki czy budowle oprogramowanie często powstaje na konkretne zlecenie konkretnego klienta z uwzględnieniem jego indywidualnych potrzeb. Jest jednak podstawowa różnica - w przypadku obiektów budowlanych prawa fizyki weryfikują każdy projekt - co więcej prawa te są takie same wszędzie. W przypadku oprogramowania takich praw nie ma. Dodatkowo też świadomość potrzeb i wymagań wśród osób decydujących o zakupie oprogramowania jest chyba jedną z najniższych ze wszystkich branż. Prowadzi to do sytuacji (niewątpliwe w pewnym sensie korzystnej dla twórców oprogramowania), w której określenie wymagań jest bardzo mgliste i rozwiązanie może przybrać dowolną formę.

Wciąż dla wielu klientów oprogramowanie to rodzaj „magii”, więc skoro mają oni do czynienia z magią, to akceptują rozwiązania proponowane im przez różnej maści „szamanów”, którzy naprędce próbują sklecić coś, za co będzie można odebrać zapłatę i uciec możliwie daleko od skutków wadliwego działania takiego produktu. Najbardziej przerażające jest jednak to, że obraz oprogramowania jako produktu tworzonego szybko i byle jak jest obecny w powszechnej świadomości od co najmniej trzydziestu lat. F. Brooks w swoim „Mitycznym osobo-miesiącu”  poruszał ten problem już w latach siedemdziesiątych ubiegłego wieku, a wciąż można odnieść wrażenie, że zjawisko to jest tak samo aktualne jak wtedy. Użytkownicy oprogramowania są bardzo pokorni i godzą się na występowanie wielu (często bardzo uciążliwych) błędów, choć gdyby podobne problemy występowałyby w ich innych urządzeniach, to tacy pokorni by nie byli. Wiele osób zarządzających przedsiębiorstwami tworzącymi oprogramowanie z całą premedytacją wykorzystuje ten fakt i dlatego niewielu jest zainteresowanych tworzeniem systemu zarządzania jakością.

System zarządzania jakością to system, który ma pozwolić m. in. na formalne określenie procesów zachodzących podczas wytwarzania produktu (w naszym przypadku oprogramowania). Jednak trudno określić jest procesy jeśli rozwój oprogramowania jest chaotyczny, nieskoordynowany i często przypadkowy. Z drugiej strony próba usystematyzowania procesu powstawania oprogramowania napotyka opór jego twórców. Twórcy oprogramowania uważają się często za swego rodzaju artystów i wszelkie procedury są przez nich traktowane jako swoiste „zabijanie duszy”. W tym oporze jest sporo racji, bowiem stosowanie procedur, które są nieżyciowe, bądź też nie odpowiadają specyfice tworzonego oprogramowania, czy też wręcz utrudniają życie jest powszechne w wielu organizacjach. Nie można się więc dziwić, że twórcy oprogramowania (którzy w końcu są chyba najbardziej wrogo nastawieni do biurokracji i wszelkich form wtłaczania ludzi w schematy, od schematu ubioru poczynając, na schemacie działania kończąc) są temu niechętni. Rolą osób wprowadzających system jakości jest takie jego przedstawienie, aby wykazać pozytywne aspekty jego wdrożenia.

Dodatkowo jeśli system ten będzie uwzględniał potrzeby konkretnej organizacji, wówczas w stosunkowo krótkim okresie czasu przyniesie on korzyści zauważalne dla wszystkich uczestników tworzenia oprogramowania. W informatyce bardzo często bowiem mamy do czynienia ze wspomnianym wcześniej chaosem - brak jest osób odpowiedzialnych za poszczególne etapy przygotowywania oprogramowania i w momencie jakichś problemów tak na prawdę nie wiadomo na którym z etapów one powstały i nie da się w takim razie zapobiec im w przyszłości. Taki bowiem powinien być cel osób zarządzających jakością - eliminacja słabych punktów w działalności organizacji, jednak żeby je wyeliminować, trzeba je najpierw znaleźć.