CTO EMBIQ o zapewnianiu jakości oprogramowania

Czy pominięcie etapu zapewniania jakości może się opłacić? Zapytaliśmy o to Bartka, CTO EMBIQ.

• Czy to prawda, że jakość musi kosztować?

Bartek: Jeśli naprawdę chcemy, możemy pominąć etap zapewniania jakości. Ale właśnie jego brak może nas kosztować. Pieniądze zainwestowane w jakość produktu wracają podwójnie: po pierwsze dlatego, że po drodze jest znacznie mniej problemów, a po drugie dlatego, że gotowy produkt jest dużo bardziej niezawodny.

• Czy przez brak jakości możemy stracić tylko pieniądze?

Bartek: Gorzej – nasz klient może stracić swoich klientów. Bez zadbania o jakość naraża się na ujawnienie lub utratę danych, przez co produkt nie będzie nadawał się do użytku, a klienci nie będą mogli normalnie z niego korzystać. Jeśli tworzymy coś dla użytkownika końcowego, to zawsze kosztuje. Często bez zapewnienia jakości taki produkt w ogóle nie nadaje się do wydania. Klienci nie zawsze zdają sobie sprawę z tego, czym jest jakość. Okazuje się, że ważny jest nie tylko sam etap wytwarzania, ale też to, co dzieje się po nim.

• Czy warto inwestować w jakość? Czy można pominąć ten etap? Czy później zapłaci się więcej?

Bartek: To zależy od tego, co chcemy osiągnąć. Wiele naszych produktów opiera się na fazie R&D, w której testów jest niewiele albo nie ma ich wcale. Gdy jednak chodzi o produkty końcowe, przeznaczone do produkcji lub wydania, nie warto pomijać tego kroku. Na początku tego nie widać, ale na końcu mogą wyjść usterki. Wtedy okazuje się, że produkt nie jest wystarczająco stabilny, by go opublikować. Z etapu związanego z jakością można zrezygnować, gdy chcemy zbudować na przykład prototyp.

• Jakie są etapy zapewniania jakości oprogramowania?

Bartek: Zapewnianie jakości zaczyna się, zanim ruszy wytwarzanie oprogramowania – od dobrze przemyślanej koncepcji produktu, funkcji, architektury i przypadków testowych. Potem, w trakcie wytwarzania, są to testy jednostkowe, automatyczne, integracyjne, manualne według scenariuszy i testy małpie (monkey tests). Zapewniania jakości nie należy jednak mylić z testowaniem, bo na jakość składa się też dobrze ustawiony proces wytwarzania oprogramowania oraz jego automatyczna, ciągła integracja.

Pierwszy krok to zaprojektowanie testów. Zakres testów jest oczywiście skończony – nasze możliwości są ograniczone. Musimy opracować koncepcję testów, tak samo jak opracowujemy koncepcję widoków czy architektury. W tej fazie trzeba więc przygotować również koncepcję wykonania testów. Dopiero potem zaczynają się pierwsze testy. Nazywamy je „przypadkami użycia” produktu – opisują one, jak użytkownik korzysta z aplikacji. To pierwszy krok na przykład w aplikacjach webowych, ale też w aplikacjach mobilnych, urządzeniach i w każdym innym obszarze.

Po tym pierwszym kroku przechodzimy do drugiej fazy – wytwarzania produktu. Na tym etapie wykonujemy kilka rodzajów testów. W zależności od rodzaju produktu czy projektu zwykle staramy się przygotować jak najszerszy zestaw testów. Zaczynamy od testów jednostkowych dla poszczególnych funkcji, a potem dokładamy testy integracyjne. Na tym etapie ważną rolę odgrywa też tester. Gdy funkcja jest gotowa i trafia do głównej gałęzi produktu, tester sprawdza ją w swoim środowisku – uruchamia swoje testy i testuje ją ręcznie.

W trzeciej fazie tester automatyzuje i opisuje swoją pracę. Chodzi o testy automatyczne, testy end-to-end i testy potencjalnego interfejsu użytkownika aplikacji. Powstają na podstawie szczegółowych scenariuszy testowych – to, co jest punktem końcowym produktu, zostaje zautomatyzowane, aby dało się powtarzać te testy jak najwcześniej.

Na przykład w testach aplikacji webowych oprócz podstawowego działania automatyzujemy też testy samego interfejsu aplikacji (API).

• Jak powinien wyglądać proces wytwarzania oprogramowania, żeby zapewnić najlepszą jakość?

Bartek: Każda zmiana przechodzi statyczną analizę kodu, sprawdzamy metryki, takie jak pokrycie kodu testami jednostkowymi, kod musi się też poprawnie kompilować bez uwag, a potem przejść pełny cykl testów automatycznych. Dopiero wtedy co najmniej jeszcze jedna osoba z zespołu przegląda zmianę i ją akceptuje albo odsyła do poprawki, jeśli zauważy coś niepokojącego.

Proces tworzenia oprogramowania zaczyna się od samego programowania. Każdy fragment powstającego kodu jest sprawdzany pod kątem jakości i bezpieczeństwa. Kod przechodzi weryfikację w 2 etapach: najpierw sprawdzają go członkowie zespołu (lider w danej technologii, który ocenia jakość kodu). Na tym etapie staramy się, by zakres weryfikacji był jak najszerszy – im więcej osób, tym łatwiej znaleźć błąd. Drugi etap to analiza statyczna, która sprawdza kod pod kątem bezpieczeństwa, stylu i formatowania. Dla każdego projektu przygotowujemy środowisko lokalne, żeby wykrywać potencjalne błędy jak najszybciej i jak najwcześniej.

Pomiędzy tymi procesami uruchamiane są testy automatyczne i testy API. Testy automatyczne startują, gdy zadanie jest skończone. Zanim tester poświęci czas na przegląd kodu, inni członkowie zespołu uruchamiają automatyczne testy integracyjne.

To standardowe kroki, które zapewniają jakość oprogramowania, tworzonego kodu i jego bezpieczeństwo.

Oczywiście nigdy nie zapominamy o kliencie. W trakcie wdrażania testów budujemy środowisko wewnętrzne oraz środowisko pośrednie do testów akceptacyjnych – klient ma wgląd w ten etap, zanim zostanie wdrożona ostateczna wersja aplikacji.

• Brzmi to tak, jakby miało trwać w nieskończoność.

Bartek: Niekoniecznie. Dobrze ustawiony i zintegrowany proces wykonuje większość pracy na serwerach, gdzie te zadania działają równolegle. Nawet gdy oprogramowaniem jest firmware urządzeń IoT, cały ten proces można dopasować do potrzeb. A poza tym każda zmiana jest tak dokładnie weryfikowana, że zespół tym bardziej się stara, by przeszła proces już za pierwszym razem.

• Czy każdy nasz projekt przechodzi tak dokładną procedurę QA?

Bartek: Zalecamy ją w każdym projekcie, ale wiemy też, że nie zawsze jest to racjonalne. Jeśli na przykład projekt powstaje w ramach pierwszej rundy finansowania i ma zbadać możliwości technologiczne przed dalszym wytwarzaniem oprogramowania, budowanie długoterminowych procesów zapewniania jakości mija się z celem – sam projekt może trwać krócej niż przygotowanie planu testów i środowiska. Przy każdym produkcie, który ma trafić do klienta końcowego, bardzo pilnujemy jednak standardów procedury QA.

Każdy z naszych projektów przechodzi tak dokładną procedurę.

Często traktujemy testy jako ostatni etap, ale zanim projekt do niego dotrze, przechodzi długą drogę. Równoległe testowanie oprogramowania jest lepsze, bo nie trzeba poświęcać dodatkowego czasu na zapewnianie jakości – wszystko dzieje się jednocześnie. W praktyce programista prawie nie zauważa testów. Do tego wykonywanie ich na serwerach sprawia, że całość bardzo dobrze się skaluje.

• Czy jakość można kupić? Czyli czy można zamówić samą usługę zapewniania jakości?

Bartek: Tak, można. Zdarza się, że realizujemy projekty, w których nie dostarczamy samego oprogramowania, tylko doradzamy i tworzymy całą związaną z nim infrastrukturę. Pomagamy określić oczekiwania funkcjonalne, tworzymy scenariusze testowe, konfigurujemy środowiska, integrujemy CI i budujemy narzędzia wspierające testy automatyczne. W końcu zajmujemy się wytwarzaniem oprogramowania od prawie 12 lat i chętnie dzielimy się tym doświadczeniem.