Jak mierzyć jakość oprogramowania?

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

Notatka o autorze:

Zajmuję się testowaniem, zabezpieczaniem i zapewnianiem jakości oprogramowania od ponad 13 lat. Rozpocząłem swoją karierę od testów manualnych i analizy biznesowo-technicznej. Obecnie prowadzę firmę Quality Island, która zajmuje się szeroko pojętym testowaniem oprogramowania oraz szkoleniami dla przyszłych i obecnych testerów oprogramowania. Moją specjalnością są testy automatyczne aplikacji webowych oraz budowa procesów automatyzacji i robotyzacji. Od 8 lat prowadzę aktywnie szkolenia oraz konsultacje z tych tematów i wykonuję zlecenia dla firm trzecich jako konsultant, ekspert oraz audytor. Współpracuję również z firmami jako osoba do rekrutacji i weryfikacji technicznych. Interesują mnie głównie tematy związane z architekturą IT oraz zagadnienia DevOps/TestOps, ponieważ ściśle wiążą się z zapewnianiem jakości oprogramowania.

 

Tomasz Stelmach

CEO&Founder

 

0 komentarzy

Wyślij komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *