Wywiad został udzielony Polskiej Agencji Prasowej i dotyczy zgłoszeń na ServiceDesku COI odnośnie ŹRÓDŁA, ale kończy się dwoma pytaniami, gdzie w odpowiedziach poruszony jest aspekt testowania.
Dobrze byłoby, gdyby termin rozwiązania [zgłoszeń - od redakcji] był jasno określony. Czy to możliwe?
- Cykl testowania i wymiany trwa zazwyczaj dwa lub trzy tygodnie, taka konkretna odpowiedź powinna więc przychodzić do zgłaszającego problem. Na pewno trzeba też stworzyć procedury awaryjne w przypadku szybkich zmian, nie powinny być one traktowane tak jak zmiany, które można spokojnie testować i sprawdzać. Problemy wymagające natychmiastowego działania nie powinny być rozwiązywane przy udziale trzech ośrodków testujących.
Jak wygląda taki proces testowania w COI?
- Mamy obecnie pokrycie testów automatycznych na poziomie między 80-90 proc. Nie siedzi więc tester i nie rejestruje ręcznie aktu. Testy automatyczne w bardzo szybki sposób sprawdzają pracę aplikacji niezależnie od pracy człowieka. To jest najszybszy sposób, a my mamy to pokrycie bardzo wysokie. Można jedynie próbować ten proces usprawnić.
Uzyskanie tak wysokiego pokrycia testami automatycznymi jest niespotykane, a w wielu organizacjach po prostu uznawane za nieopłacalne biznesowo. Ponieważ jest to dla nas bardzo ciekawy temat, postanowiliśmy pogłębić informacje ujawnione w artykule. Jeden z naszych redaktorów zdecydował się napisać do COI. Otrzymaliśmy odpowiedzi od Artura Helmana, kierownika Zespołu Produkcji Oprogramowania.
W jednym z wywiadów Monika Jakubiak powiedziała, że pokrycie testami automatycznymi jest na poziomie 80-90%. Czy to zgodne z prawdą?
Należy sprecyzować tę informację. Jeżeli mówimy tutaj o SRP, to pokrycie testami zależy od poszczególnych modułów i waha się między 50% a 90%. Można uznać, że dla głównych funkcjonalności systemu pokrycie jest na poziomie 80%.
Jak liczone jest takie porycie?
Pokrycie testami jest liczone przy użyciu specjalistycznych narzędzi, takich jak SonarQube.
Dlaczego zdecydowano się na testy automatyczne?
Głównymi czynnikami decydującymi była oszczędność czasu i zasobów ludzkich. Oszczędzamy czas na powtarzalnych testach manualnych. Najważniejsze jest jednak to, że dzięki testom sprawdzamy poprawność implementacji, tj. czy dla reprezentatywnych danych zwracane są oczekiwane rezultaty oraz regresję, czyli czy podczas rozwijania aplikacji nie wprowadziliśmy nowych błędów tam, gdzie ich wcześniej nie było.
Przy pomocy jakich narzędzi stworzono testy automatyczne?
Przy pomocy Selenium WebDriver, Junit, Arquillian.
Jaka jest architektura tych testów?
Opisując ten proces krok po kroku można to przedstawić tak:
- Na podstawie wymagań klienta oraz analizy tworzymy kod aplikacji oraz scenariusze testowe.
- Dla kodu piszemy testy jednostkowe.
- W oparciu o scenariusze przygotowujemy kod testów integracyjnych.
- Testy są uruchamiane po zbudowaniu aplikacji w Jenkinsie.
- W przypadku jeśli te testy nie przechodzą, to oznacza, że kod jest do poprawki.
[AKTUALIZACJA]
Udało nam się uzyskać doprecyzowanie informacji, jakie stały się podstawą do naszego negatywnego komentarza. Poniżej odpowiedź:
"(…) Najważniejsze jest to, że dzięki testom sprawdzamy poprawność implementacji, tj. czy dla reprezentatywnych danych zwracane są oczekiwane rezultaty. Sprawdzamy także regresję, czyli czy podczas rozwijania aplikacji nie wprowadziliśmy nowych błędów tam, gdzie ich wcześniej nie było. Dodatkowo oszczędzamy czas i zasoby ludzkie na powtarzalnych testach manualnych. Unikamy zmęczenia ludzi rutyną.
Dzięki temu, że mamy pokrycie kodu i testy zbudowane na kolejnych etapach i środowiskach oraz wykorzystane różne rodzaje testów, każda kolejna procedura testowania weryfikuje dodatkowo poprzednią.
Oprócz tego wykonujemy też testy manualne: funkcjonalne, pozafunkcjonalne oraz akceptacyjne.
Weryfikujemy zmiany zarówno w aplikacjach, jak i w środowiskach utrzymujących te aplikacje.
Testy automatyczne dzielą się na testy samego kodu, testy funkcjonalności oraz pozafunkcjonalne.
W ramach testów kodu wyróżniamy testy jednostkowe, do których wykorzystujemy takie narzędzia, jak JUnit, AssertJ, itp, oraz testy integracyjne, w których testujemy większy fragment kodu, wraz z dodatkowymi elementami, takimi jak baza danych czy serwer aplikacyjny.
W ramach testów funkcjonalności stosujemy narzędzia umożliwiające wykorzystanie gotowych danych oraz symulację przeglądarki i innych systemów lub urządzeń. W tym przypadku wykorzystujemy Selenium WebDriver.
W ramach testów pozafunkcjonalnych wykonujemy m.in. testy wydajnościowe, podczas których sprawdzamy zarówno działanie fragmentów aplikacji, jak i całych środowisk pod obciążeniem. Stosujemy standardowe narzędzia, takie jak Jmeter czy jmh. Testy bezpieczeństwa również przeprowadzamy wspierając proces manualny narzędziami automatyzującymi, takimi jak nessus, nexpose, metasploit, burp suite, itp.
Pokrycie testami automatycznymi jest liczone dla kodu źródłowego z testów jednostkowych i integracyjnych. Sprawdzamy pokrycie kodu pod względem liczby linii, które zostały wykonane w trakcie przebiegu testu, oraz wszelkich rozgałęzień w tym kodzie. Używamy standardowych bibliotek dla poszczególnych języków. Dla javy jest to np. SonarQube i jacoco.
Każda zmiana jest testowana atomowo i równolegle na poziomie mechanizmu pull-request. Dzięki temu nie blokujemy pracy poszczególnych programistów i zachowujemy pełną historię zmian. W zależności od elementu, którego dotyczy uruchamiane są odpowiednie testy automatyczne oraz z pomocą zespołu testerów przeprowadzane są testy manualne.
Taka zmiana jest propagowana między środowiskami: od stacji roboczej przez środowiska testowe, integracyjne, akceptacyjne, stage, aż po środowisko produkcyjne. W ten sposób weryfikujemy integrację z coraz większą liczbą rzeczywistych systemów. Pozytywny efekt testów automatycznych i manualnych jest niezbędny do propagacji na kolejne środowiska."
Komentarz
Z odpowiedzi wynika, że określane pokrycie na poziomie „90%” uzyskuje się jako miary uruchomienia kodu. Metryki dla pokrycia interfejsu automatami nie są monitorowane jako osobny parametr. Jest to podejście niespotykane w znanych nam przypadkach. Zazwyczaj uruchomienie testów jednostkowych jest odseparowane od uruchomienia automatów na interfejsie. Podejście prezentowane przez COI jest nietypowe, ale ciężko jednoznacznie określić je jako niepoprawne.
Potwierdza się na pewno, że wysokiej jakości kod niekoniecznie przekłada się na akceptowalną przez odbiorców aplikację. Oczywiście kwestia pokrycia oprogramowania automatami nie miałaby żadnego znaczenia jeśli ŹRÓDŁO nie byłoby tak koszmarnie źle wdrożone i nie borykało się ciągle z setkami defektów.
Centralny Ośrodek Informatyki o sobie: "COI to think tank, centrum kompetencji informatycznych (IT) i instytucja publiczna w jednym. Jesteśmy nie tylko ekspertami IT, ale także projektujemy usługi i doświadczenie użytkownika, szkolimy, prowadzimy komunikację społeczną, zarządzamy projektami i zamówieniami publicznymi. Dzięki temu możemy realizować kluczowe projekty cyfrowe w państwie od A do Z."
ŹRÓDŁO - aplikacja do obsługi Systemu Rejestrów Państwowych.