Wszyscy mamy świadomość, że właściwa jakość oprogramowania, które dostarczamy klientom wewnętrznym jak i zewnętrznym, jest niezbędna w dzisiejszych czasach. Sposób wytwarzania i dostarczania systemów informatycznych ewoluuje. Obecnie dominuje przyrostowy sposób wytwarzania oprogramowania z możliwością częstej adaptacji względem oczekiwań biznesu i użytkownika końcowego. I kluczowe jest to, by wytworzone oprogramowanie, które oczywiście daje wartość biznesową, było dostarczone na czas i w oczekiwanej jakości.
Jednym z najistotniejszych elementów, by to osiągnąć, jest możliwie wczesne zapewnienie jakości w cyklu wytwórczym. Stąd obecnie bardzo popularne jest stosowanie terminu Shift-Left Testing, niezależnie od modelu wytwarzania oprogramowania, który można parafrazować jako „testuj wcześnie i często”.
Bardzo dobrze strategię wczesnego testowania ilustrują wykresy na bazie danych z książki Capers Jones-a „Applied Software Measurement: Global Analysis of Productivity and Quality”. Przedstawiają one ilość (wyrażoną w %) błędów/defektów wprowadzanych na każdym z etapów wytwarzania oprogramowania. (patrz: brązowa linia)
Capers Jones-a „Applied Software Measurement: Global Analysis of Productivity and Quality”.
Legenda:
Jak widać większość błędów jest wprowadzana na etapie kodowania - co w gruncie rzeczy wydaje się logiczne. Na tym etapie rodzą się pomysły i rozwiązania, mogą pojawić się błędy wynikające z niekompletnych założeń, niezrozumienia wymagań, niedostatecznej wiedzy domenowej, trudności integracji rozwiązania pomiędzy różnymi systemami itp. itd.
Patrząc na drugą zamieszczoną linię (patrz: niebieska linia) przedstawiającą ilość (%) wykrytych błędów, widać jak ilość znalezionych błędów przyrasta wraz z rozpoczęciem testów na kolejnych etapach wytwarzania oprogramowania, aż do wydania. Warte spostrzeżenia jest to, że na etapie kodowania praktycznie nie są wykrywane wprowadzone błędy.
I w końcu trzecia linia (patrz: czerwona linia) przedstawia koszt naprawy defektu na poszczególnych etapach wytwarzania oprogramowania. Widać jak na dłoni, że najmniejszy koszt usunięcia błędu jest na wczesnych etapach, a następnie gwałtownie wzrasta pod koniec procesu. Koszt naprawy błędu wykrytego na etapie testów systemowych jest czterdziestokrotnie większy, niż gdyby był wykryty na etapie kodowania, a dziesięciokrotnie jeśli by go wychwyciły testy jednostkowe. Natomiast koszt usunięcia defektu, który przedostał się na produkcję jest dramatycznie większy niż na wczesnych etapach procesu wytwórczego.
Im później tym dojście do tego, gdzie znajduje się przyczyna wadliwie działającego oprogramowania, jest bardziej kosztowna. Wymaga poświęcenia znacznej ilości czasu i często angażuje wiele osób, nie tylko z zespołu wytwórczego, ale i spoza niego. Wpływ późno wykrytego defektu może nieść też za sobą konieczność wprowadzenia zmian, które w swoim następstwie mogą powodować kolejne dodatkowe prace analityczne, programistyczne, testowe etc.
Stąd dość jasno nasuwa się logiczny wniosek, że trzeba wykrywać defekty jak najwcześniej – można powiedzieć „im wcześniej tym lepiej”.
Dlatego podejście określane jako wczesne testowanie można zobrazować poniższym diagramem:
Capers Jones-a „Applied Software Measurement: Global Analysis of Productivity and Quality”.
Legenda:
Staramy się przesunąć moment znalezienia defektu, tam gdzie usunięcie go będzie możliwie najmniejszym kosztem.
Jak możemy przesunąć moment znalezienia defektu jeszcze bardziej na lewo niż na powyższym wykresie? Tutaj z pomocą mogą nam przyjść narzędzia do analizy statycznej kodu. Dostępne na rynku produkty oferują już na tyle kompleksowe podejście, że nie tylko są w stanie wykryć błędy w „świeżo” napisanym kodzie. Pomogą w wykryciu kodu który jest napisany nie zgodnie dobrymi praktykami, wykryć podatności bezpieczeństwa, usunąć zduplikowany/zbędny kod itd.
Podsumowując – to podejście wygląda bardzo racjonalnie i logicznie, a wręcz jest nieodzowne jeśli idziemy ścieżką podejść zwinnych w wytwarzaniu oprogramowania z kierunkiem wskazującym na DevOps. Przy założeniu, że myślimy o DevOps, który uwzględnia również ciągłe testowanie (DevTestOps) i dbanie o bezpieczeństwo (DevSecOps) 😉
Tomasz Maj - Kierownik Sekcji Testów i Zapewnienia Jakości Oprogramowania
.jpg)
.png)