5 faktów o testowaniu, które musi znać każdy CEO

Ostatnio trafiłem na filmik Daniela Knotta skupiający się na istocie testowania oprogramowania z punktu widzenia CEO czy ogólnie kadry menadżerskiej. Poruszanie takich tematów jest ważnym krokiem w walce z mitami o testowaniu - zainspirowany wspomnianym materiałem, postanowiłem dołożyć swoją cegiełkę.

Biznesowa strona organizacji raczej nie zagląda w głąb procesu testowania (normalna rzecz, nie ma w tym nic złego) - oprogramowanie ma po prostu działać. I choć testowanie zdaje się być odległe od obowiązków biznesu, warto uświadamiać, że wpływa na aspekty, które przez biznes są już jak najbardziej zauważalne.

Testowanie to coś więcej niż szukanie bugów

Przede wszystkim - testowanie jest czymś więcej niż klikaniem po aplikacji w poszukiwaniu błędów. Jasne, wykrywanie bugów to część pracy testerów. Ale dział QA odpowiada też za spojrzenie na oprogramowanie z perspektywy klientów. Aplikacja ma rozwiązywać problemy użytkowników. I nawet jeśli oprogramowanie jest wolne od bugów, to nie znaczy, że spełnia wymagania klientów. A tester z odpowiednią wiedzą domenową jest w stanie przewidzieć potrzeby użytkowników.

Testowanie jest ważne z perspektywy sprzedaży

Co prawda, pracy testerów nie da się sprzedać (w przeciwieństwie do kodu pisanego przez programistów), ale nikt nie chce korzystać z oprogramowania wypchanego błędami. Niezadowolenie użytkownik na pewno nie wpłynie korzystnie na sprzedaż czy zawierane umowy. A liczba bugów "wypuszczonych" do klienta jest ściśle związana z testowaniem.

Shift-left testing to podstawa

"Testuj wcześnie i często" - Larry Smith, twórca pojęcia shift-left testingu. Testowanie rozpoczynane na wczesnym etapie tworzenia oprogramowania jest nazywane przesunięciem testowania w lewo. Wcześnie wykryte błędy są tańsze w naprawie. Testowanie nie powinno więc być tylko procesem sprawdzania gotowych funkcjonalności (bo napisany kod to dość daleki etap w cyklu życia oprogramowania) - rozpoczęcie weryfikacji już podczas określania wymagań biznesowych pozwala na zidentyfikowanie wielu problemów.

Automatyzacja nie jest głównym celem

Testy automatyczne powinny pomagać w procesie utrzymania jakości, a nie stanowić fundament testowania. Nie możemy zapominać, że wyłącznie dobra automatyzacja testów ma pozytywny wpływ na jakość oprogramowania. Celami idealnymi do automatyzacji są obszary krytyczne z biznesowego punktu widzenia. Niektóre ścieżki aplikacji muszą działać zawsze. Warto też automatyzować powtarzalne testy - to ułatwia sprawdzanie regresji.

Ale decyzję o automatyzacji należy podjąć z uwzględnieniem długofalowych kosztów. To nie jest tak, że testy napiszemy raz i już nie musimy do nich zaglądać. Testy automatyczne wymagają regularnych aktualizacji - a to niesie za sobą sporo pracy (i kosztów).

Organizacja powinna inwestować w jakość

Nie ma co ukrywać, że dbanie o jakość oprogramowania sprowadza się do zadowolenia klienta. Zadowolony klient jest skłonny do kupna produktu czy dalszej współpracy. Inwestycja w proces utrzymania jakości powinna więc być naturalnym krokiem organizacji. Ciągły rozwój testerów czy gotowość do przyjęcia pomysłów (np. nowych rodzajów testów, usprawnień wdrożeń do klienta) odpłaci się mniejszą liczbą bugów i większym zaufaniem do oprogramowania.

Powód do dumy 😄

Co o tym myślisz? Daj znać w komentarzu:

Chcesz być na bieżąco? Zapisz się do newslettera!

Polecane wpisy:

Sprawdź też moje social media: