Istnieją różne cele testowania oprogramowania. Jednym z głównych celów testowania jest mierzenie jakości oprogramowania. Czym zatem jest ta tajemnicza „jakość”?

Jakość oprogramowania to zestaw istotnych cech, które wyróżniają dane oprogramowanie – negatywnie lub pozytywnie.

Jak mierzyć jakość oprogramowania? – miary jakości

Pomyślmy zatem jakie mogą być miary jakości? Od razu pewnie na myśl przychodzi nam – opisowa miara jakości, czyli po prostu opis słowny. Jednak taka miara bywa bardzo zwodnicza – w końcu takowa miara zależeć będzie od podmiotu, który stworzył opis, w szczególności od jego subiektywnych odczuć i interpretacji. Należy zatem wystrzegać się tak sporządzonej opisowo miary jakości. Powinniśmy za to przede wszystkim stosować miary liczbowe, metryki  w kontekście mierzenia jakości oprogramowania. W końcu: „liczby nie kłamią!”. Należy wykorzystać przede wszystkim fakty liczbowe, aby stworzyć końcowa analizę jakościową.

Jak wspomniałem wcześniej podstawowym parametrem miary jakości oprogramowania powinno być kryterium ilościowe. Według takiego kryterium opisujemy proporcję błędów wykrytych w fazie produkcji oprogramowania do liczby błędów, wykrytych już w fazie odbiorczej przez klienta końcowego . Możemy takie kryterium ilościowe przedstawić na grafie – może on wyglądać np. tak:

Jakość oprogramowania – wagi błędów

Stosując tego typu kryterium ilościowe powinniśmy przyjąć jakąś wartość graniczną, która stanie się dla nas pewnym wyznacznikiem, a w momencie przekroczenia będzie dla nas jasnym ostrzeżeniem, alertem, który wymusza na nas podjęcie działań zaradczych. Podkreślam raz jeszcze, że jest to parametr ilościowy, a więc nie rozróżnia on wagi błędów (np. krytyczny, wysoki, średni, niski itp.) a jedynie bierze pod uwagę ich ilość. Oznacza to, że dla kryterium ilościowego – błędy krytyczne są na równi z błędami niskimi, mało znaczącymi incydentami, czy nawet zwykłymi literówkami. Zatem w tym momencie powinna zapalić nam się w głowie czerwona lampka ostrzegawcza, która sygnalizuje nam, że sam parametr ilościowy może nie wystarczyć do poprawnej miary jakości oprogramowania. Parametr ilościowy powinniśmy zatem uzupełnić o parametr „wagi błędu” – w końcu jeden błąd krytyczny nie równa się jednemu błędowi o niskiej wadze.

Jakość oprogramowania – feedback

Oczywiście wyżej przedstawione kryterium ilościowe nie powinno być jedynym miernikiem jakości oprogramowania. Kolejnym ważnym aspektem miary jakości powinien być feedback od użytkowników końcowych, klientów. Opinie użytkowników powinniśmy skonfrontować z wyżej opisanymi parametrami i ich statystykami. Feedback możemy zbierać np. za pomocą ankiet. Takie zestawienie powinno dać nam informacje potwierdzające lub zaprzeczające trafności pomiarów liczbowych, przyjętych granic. Na tej podstawie możemy nieco skorygować przyjęte wcześniej progi tak, aby jeszcze lepiej oddawały faktyczny stan oprogramowania. Sam proces testowania oprogramowania, czy mierzenia jego jakości zwykle jest złożony i skomplikowany – gdyż istnieją różne rodzaje błędów, usterek, a także ich okoliczności występowania. Wysoka liczba błahych do wykrycia błędów  znalezionych przez klientów– zawsze źle świadczy o jakości danego produktu. Natomiast istnienie błędów, które pojawiają się tylko w rzadkich, specyficznych sytuacjach (które ciężko jest wykryć podczas standardowej pracy z oprogramowaniem) – zwykle dobierana jest dużo bardziej wyrozumiale. Dlatego kolejnym ważnym parametrem w przeprowadzaniu miary jakości oprogramowania jest parametr określający stosunek wagi błędu do poziomu skomplikowania sytuacji jego wystąpienia.

W dużym skrócie omówiliśmy sobie parametry, które mogą pomóc zmierzyć jakość oprogramowania. Teraz zobaczymy jakie konkretnie atrybuty aplikacji powinniśmy poddać testowaniu i weryfikacji, aby uzyskać wystarczającą pewność co do jakości oprogramowania. Poniższe atrybuty oprogramowania będą zatem naszymi punktami kontrolnymi:

• Funkcjonalność
• Niezawodność
• Przenośność
• Wydajność
• Pielęgnowalność
• Użyteczność
• Bezpieczeństwo
• Przydatność dokumentacji

Oczywiście każdy powyższy punkt kontrolny odnosi się do innej właściwości oprogramowania, dlatego powinniśmy wykonywać osobne testy właściwe dla każdego ze wskazanych atrybutów oprogramowania. Dobrze jest, aby klient zamawiający oprogramowanie – wskazał, które atrybuty oprogramowania są dla niego najważniejsze, a które mają mniejsze znaczenie. Np. klient może wskazać, że aplikacja bezdyskusyjnie musi działać w trybie ciągłym – musi być niezawodna (gdyż np. każda jej niedostępność niesie za sobą duże straty finansowe) a np. może przymknąć oko na niedoskonałości dokumentacji. Takie informacje powinniśmy uzyskać na samym początku  – podczas fazy planowania i powinny być zapisane w dokumencie Planu Testów. Na podstawie takich informacji będziemy wiedzieć na czym powinniśmy skupić największą uwagę i swoją pracochłonność, a co możemy zostawić do testów na koniec, czy nawet w skrajnych przypadkach pominąć.

Na koniec chciałbym zwrócić uwagę na jeszcze jeden bardzo ważny aspekt, który bywa często niewłaściwie rozumiany.

Pamiętajmy:

Jakość oprogramowania podnosi się wraz z naprawianiem błędów, a nie ich znajdywaniem!

Proces mierzenia jakości oprogramowania powinien odbywać się przez cały czas w fazie developmentu. Oczywiście każdy projekt ma swój koniec i termin oddania  więc przychodzi również czas na generalną miarę jakości oprogramowania, w której biorą udział również klienci. Pamiętajmy o tym, że najważniejszą miarą, która powinna mieć dla nas (zespół developerski, testerski) znaczenie jest realne zadowolenie klienta z otrzymanego oprogramowania. W końcu celem każdej wytworzonej aplikacji, jest spełnianie biznesowych zadań naszych klientów. To klient końcowy wystawia nam ostateczną ocenę i rozlicza nas za wyprodukowane oprogramowanie. Pamiętajmy również o tym, że nie ma oprogramowania wolnego od błędów – są tylko nieznalezione defekty! Dlatego pamiętajmy, aby wyciągać wnioski z każdego procesu testowego (nawet tego niezupełnie udanego czy dobrze ocenionego) i w ten sposób podnosić swoje umiejętności, a w konsekwencji jakość kolejnych projektów.

Autor: Tomasz Stelmach