Metryki testowania oprogramowania

QA

Proces tworzenia aplikacji, rozumiany jako pisanie linijek kodu i testowanie, jest zawsze wielkim wyzwaniem zespołu. Kiedy oddaje się gotowy produkt, ma się przekonanie, że wykonano go z należytą dbałością o szczegóły i bezbłędnie. Potem jednak pojawiają się pierwsze uwagi.
Czy nasze zestawy testowe pokrywają całą aplikację ? Ile defektów odnaleźliśmy podczas testowania ? A ile defektów zostało odnalezionych przez interesariusza ? Jakie jest ryzyko oddania wadliwej aplikacji w ręce klienta ?
I najważniejsze pytanie – Czy jesteśmy skuteczni w naszym działaniu?

Na większość z tych pytań znajdziemy odpowiedź w podstawowych metrykach badających nasz proces testowania oprogramowania. Możemy wyróżnić dwa główne rodzaje takich metryk:

  • Metryka wyników: używamy w niej bardzo konkretnych danych, które są miarą zakończonego działania bądź procesu.
    • Przykład: Czas pomiędzy retestowaniem poprawionego błędu do ilości błędów.
  • Metryka predykcyjna:  tutaj używamy danych, które dostarczą nam informacji jak najszybciej o możliwości wystąpienia niekorzystnych rezultatów.
    • Przykład: Ilość czasu poświęcanego na naprawę zgłoszonego błędu do ilości błędów.

Wydajność i śledzenie testów

Proces śledzenia testów jest bardzo istotny podczas tworzenia oprogramowania. Wykorzystując poniższe wzory, możemy w prosty sposób określić jakość naszych zestawów testowych. Daje nam to zwinną możliwość oszacowania ryzyka danej wersji, która jest planowana w najbliższym wydaniu.

Procentowo wskazujemy liczbę testów, które przeszły “poprawnie”

Procentowo wskazujemy ile testów zostało zakończonych niepowodzeniem.

Dzięki powyższym wzorom możemy obliczać wyniki testów automatycznych, między innymi:

  • wydajnościowych
  • funkcjonalnych
  • obciążeniowych

Istnieją również metryki umożliwiające zarządzanie defektami i prezentowanie wyników w sposób procentowy.

W sposób procentowy badamy ilość naprawionych defektów – bardzo przydatna metryka podczas porównywania procesu testowania względem wersji nowszej do starszej.

Procentowy wykaz jakości zgłaszanych defektów. Odzwierciedla ilość defektów, które zostały zweryfikowane i potwierdzone.

W tym przypadku procentowo wykazujemy ilość defektów, które zostały zweryfikowane i odrzucone ze względu na to, że zaraportowana rzecz, nie jest defektem a np. funkcjonalnością.

W sposób przejrzysty wykazujemy procentowo ile defektów krytycznych posiada/posiadała dotychczas aplikacja. Tą sama metrykę możemy wykorzystać do wyliczania procentowego każdego z przyjętych priorytetów w projekcie.

W przejrzysty sposób wykazaliśmy klientowi jak wygląda/wyglądała sytuacja z defektami odkrytymi podczas testowania aplikacji. Wszystko prezentuje się bardzo czytelnie. Pojawia się natomiast zasadnicze pytanie: jakie ponosi się koszta związane z defektami ? Ile kosztuje poprawa błędu w aplikacji ?

W tym przypadku, możemy wykazać jak wyglądają koszta za pomocą metryki:

Rozważmy taką sytuację:

Koszt roboczogodziny specjalisty oscyluje w okolicy 80 złotych. Poświęcił on około 1614,45 godzin na poprawienie 180 defektów naszej aplikacji.

Stosując powyższy wzór obliczymy, że średni czas poświęcany na poprawę jednego defektu wynosi 9 godzin. W momencie, gdy mnożymy wynik przez koszt jednej roboczogodziny dewelopera uzyskujemy kwotę 720 zł przypadającą na poprawę jednego defektu. Co daje nam całkowity koszt poprawy 180 defektów wynoszący 129600 zł

Kolejną kategorią metryk testowania oprogramowania, która umożliwia nam weryfikację stanu zestawów testowych pod względem wymagań jest pokrycie testowe. Oczywiście, jak w większości metryk testowania oprogramowania, wyniki są podawane procentowo.

Powyższe obliczenia sygnalizują w sposób przejrzysty, czy zestawy testowe należy wzbogacić o kolejną dawkę testów. Należy jednak pamiętać, że wartość podstawiona pod Ilość testów wykonanych jest liczbą nieuwzględniającą testy, które zostały wyłączone z kampanii testowej.

Druga metryka, która znajduje zastosowanie w omawianej kategorii metryk, jest metryką wymaganego pokrycia. Dzięki niej uzyskujemy informacje na temat brakującej wartości pokrycia. Kontrolowanie tej wartości jest bardzo ważne, ponieważ przy ciągłym i dynamicznym rozwoju aplikacji, dbanie o stan zestawów jest istotnym i kluczowym etapem procesu testowania.

Uzyskiwanie wyników odzwierciedlających faktyczny stan aplikacji jest czymś do czego stale dążymy. Dane, które przyjmujemy do obliczeń powinny być maksymalnym zakresem wymaganego pokrycia projektowego i zakresem pokrycia w danym procesie tworzenia nowej wersji bądź wydanej wersji. Powinniśmy też mieć świadomość, że do wykonywania wyliczeń musimy brać testy powiązane z danym wymaganiem, a nie ich wyniki (część testów może zostać wyłączona, ze względu na trwające poprawki, dzięki czemu wynik może być niedokładny).

Skuteczność testu przy użyciu efektywności defektów

Ostatnią z podstawowych kategorii i zarazem najważniejszą, jest skuteczność zespołu i jego efektywność. To właśnie za pomocą tej metryki zyskujemy odpowiedzi na pytania: jak efektywny jest nasz zespół, jak dobrze zespół testuje daną wersję produktu oraz jakie jest ryzyko wykrycia błędów po oddaniu wersji produktu klientowi?

Uzyskanie wysokiego wyniku daje nam świadomość, że zestawy testowe spełniają założenia określone w wymaganiach projektowych, a także minimalizuje ilość czasu potrzebnego na utrzymanie zestawu testowego zarówno w trwających, jak i przyszłych realizacjach projektowych.

Przykład: wynik na poziomie 64,5%, gdy dokonujemy obliczeń względem ostatniej wersji produktu, oznacza że podczas testowania oprogramowania przed jego wydaniem zespół znalazł 64,5% całej liczby wykrytych błędów błędów. Pozostałe 35,5 % błędów zostało odkryte po wydaniu nowej wersji produktu.

W przypadku tej metryki musimy mieć świadomość o trzech istotnych rzeczach:

  • Jeśli prowadzimy wyliczenia za pomocą tej metryki, będzie to idealna podstawa do rozmowy podczas retrospekcji i dyskusji na temat dodania nowych bądź ulepszenia testów w naszym zestawie testowym.
  • Ze względu na to, że przetestowanie wszystkiego nie jest możliwe, skuteczność nigdy nie będzie wynosić 100%, dlatego nie załamujcie się, a starajcie się uzyskać jak najwyższy wynik.
  • Aby zmierzyć jakość zmian wprowadzanych w celu poprawienia procesu testowania i zestawu testów, musimy kontrolować średnią efektywność do ilości defektów nie odnalezionych przez nas zespół. Zobrazuje nam to wysiłek, który został wykonany podczas tworzenia nowej wersji produktu.
Paweł Gwozdecki

Paweł Gwozdecki 14.09.2018

Pasjonat testowania oprogramowania z półtorarocznym doświadczeniem. Na co dzień pracuje jako specjalista ds. automatyzacji testów i poszerza swoją wiedzę z zakresu zarządzania procesem testowania oprogramowania.

Comments are closed.