Redakcja
Poniżej skupimy się na najważniejszych metrykach produktowych, które pomagają nam zmierzyć pewne cechy produktu. Metryki jakości oprogramowania zbierane są w całym procesie jego wytwarzania i poprzez wartości liczbowe lub odpowiednie kryterium próbują określić jakiej jakości jest wytwarzany / wytworzony produkt.
Metryka jakości wynikająca z defektów
Podstawową metryką jakości, nazywaną również metryką złej jakości, jest pokazanie defektów z podziałem na grupy ilości lub odsetki defektów sklasyfikowanych według danej kategorii (np. wg źródła defektu). Świadomość liczby defektów oraz ich wagi pozwala nam określić jak źle (jak dobrze) działa nasze oprogramowanie. Metryka ta może być rozszerzona o trend pokazujący dzienne tempo przybywania defektów, które może być powiązane z kryterium wyjścia (np. nie znaleziono nowych defektów przez tydzień). Interpretacja w takich okolicznościach jest uproszczona – im mniej defektów się pojawia, tym lepszej jakości i bardziej stabilne mamy oprogramowanie. Możemy użyć również metryki MTBF, która pokazuje nam, co jaki czas występują awarie w oprogramowaniu. Im dłuższy czas, tym bardziej niezawodne oprogramowanie udało nam się skonstruować.
Patrząc z drugiej strony, jeśli poprzez czynności kontrolne nie możemy zlokalizować w oprogramowaniu defektów, oznacza to, że albo dobrana przez nas technika nie ma skuteczności wykrywania awarii, albo oprogramowanie jest już wysokiej jakości. Ostateczną miarą zawsze będzie sprawdzenie łącznej liczby zgłoszonych (znalezionych) defektów w stosunku do łącznej liczby rozwiązanych (naprawionych).
Metryki związane z ryzykami
Jeśli w projekcie określamy, w jaki sposób oprogramowanie może zawieść (ryzyka produktowe), to poprzez weryfikację tych negatywnych scenariuszy możemy potwierdzić, że dane zdarzenie nie wystąpi, a jeśli wystąpiło, to możemy je skorygować. Taka metryka to przede wszystkim odsetek ryzyk w oprogramowaniu całkowicie pokrytych testami, które zakończyły się statusem "zaliczone". Dzięki takiej mierze wiemy, że w przewidzianym przez nas zakresie potencjalnego, niepoprawnego działania, oprogramowanie zachowuje się poprawnie.
Metryki związane z pokryciem
Różnego rodzaju projektowe czynności mogą pozwolić na uzyskanie weryfikacji poprawności implementacji oprogramowania. Mapują się one zazwyczaj na specyfikację opisującą zachowanie oprogramowania. Taka kompletność weryfikacji opisanych funkcji i atrybutów nazywana jest pokryciem. Najpopularniejszą czarnoskrzynkową metryką będzie pokrycie wymagań przez testy z ich statusami wykonania. Pokrycie możemy uzyskać również dla zdefiniowanych dla danego oprogramowania środowiska / konfiguracji wraz ze statusami wykonania testów. Jeśli potraktujemy kod źródłowy jako inną formę notacji zachowań się oprogramowania, to jego jakość możemy również potraktować miarą pokrycia kodu ze statusami wykonania testów.
Metryki poświęconego czasu lub budżetu na weryfikację
Czas oraz środki poświęcone na weryfikację oprogramowania w powiązaniu z uzyskanym pokryciem, lub znalezionymi defektami może również sugerować nam, czy oprogramowanie jest wysokiej jakości. Przykładowo, jeśli projekt programistycznie kosztował 100 jednostek, sama jego weryfikacja 50 jednostek, a dodatkowo nie znaleziono poważnych problemów, to jest szansa, że oprogramowania ma akceptowalny poziom jakości. W przypadku projektowania testów metryka ta może być określana jako całkowita liczba wykonanych testów z podziałem na zaliczone, niezaliczone, zablokowane i pominięte.
Metryka wynikająca z akceptacji końcowego odbiorcy oprogramowania
Akceptacja zazwyczaj będzie zero – jedynkowa. Końcowy odbiorca po własnej weryfikacji jakości oprogramowania jest z niego zadowolony i decyduje o jego wdrożeniu. Oczywiście nie oznacza to, że podczas testów akceptacyjnych nie wykryto żadnych defektów, jednak zakłada się, że są one na tyle pomijalne, że pomimo ich obecności oprogramowanie zostaje zaakceptowane. W podejściach zwinnych określono to jako jedyną i ostateczną miarę jakości oprogramowania "działające oprogramowanie", wywodzone z przekonania, że skoro dana osoba (grupa) zamawia oprogramowanie, to może ona również potwierdzić, że to oprogramowanie działa.
Czasami stosujemy także pośrednie miary weryfikacji jakości poprzez badanie zaufania do oprogramowania mierzonego poprzez ankiety (często raportuje się je subiektywnie). Jest to metryka dość kontrowersyjna, ale potrafi być bardzo wartościowa.
Miary i metryki mają kolosalne znaczenie dla budowania świadomości jakości oprogramowania. Nawet jeśli naszym jedynym kryterium gotowości oprogramowania do wydania jest "działające oprogramowanie", to jest to również miara.
