Tylko do końca lipca możesz skorzystać z opcji DOFINANSOWANIA 60% ceny na dowolne szkolenie! Złóż wniosek

Zapraszamy na darmowy WEBINAR: Podstawy organizacji testów: doświadczenia z projektów – 08.08.2024. Zapisz się.

Testowanie statyczne

Czym jest testowanie statyczne?

Testowanie statyczne jest metodą testowania, służącą do wyłapywania błędów i nieścisłości. Zazwyczaj jednak testerzy wolą pracę z bezpośrednim wykorzystaniem aplikacji, gdyż jest ona ciekawsza i szybciej można zobaczyć efekty swoich działań. Czym konkretnie jest  testowanie statyczne? Jakie są jego zasadnicze cechy i czym różni się ono od testowania dynamicznego? Wyjaśniamy.

Testowanie statyczne — co to jest?

Mianem testowania statycznego, określa się metodę testowania oprogramowania, która polega na przeglądaniu oraz statycznej analizie kodu dokumentacji bez konieczności fizycznego uruchamiania aplikacji. Tego typu testowanie pozwala na wykrycie istotnych błędów i nieprawidłowości jeszcze na wczesnym etapie prac. Przeoczenie wad w tej fazie może spowodować olbrzymie straty. Testowanie statyczne umożliwia nie tylko identyfikację, ale również korygowanie błędów jeszcze przed uruchomieniem oprogramowania. Rozpoczyna się ono na wczesnym etapie życia oprogramowania i kończy w trakcie procesu weryfikacji.

Podczas testowania statycznego aplikacja sprawdzana jest za pomocą przeglądu i analizy. W celu upewnienia się, że kod jest poprawny, testerzy muszą przestrzegać rygorystycznych procedur testowania. Ma ono na celu wyłapanie błędów z fazy zbierania wymagań SDLC, czyli cyklu rozwoju oprogramowania, aż po kod źródłowy. Testy statyczne można wykorzystywać do wykrycia defektów w fazach dokumentacji, co jest pomocne w zapobieganiu błędom na późniejszych etapach.

Przeglądy te powinny być wykorzystywane we wszystkich istotnych aspektach tworzenia oprogramowania, czyli w wymaganiach, projektowaniu, implementacji, testowaniu i utrzymaniu. Typami wad, które zdecydowanie łatwiej wykryć podczas testów statycznych, są różnego rodzaju odchylenia od standardów, brakujące elementy wymagań, wady projektowe, niespójne specyfikacje interfejsów i inne.

Testowanie statyczne a dynamiczne — różnice

W odróżnieniu od testowania statycznego, podczas testowania dynamicznego wykonywany jest kod modułu lub systemu i konieczne jest uruchomienie oprogramowania. Poniżej podajemy najistotniejsze cechy różniące testowanie statyczne od dynamicznego.

Testowanie statyczne:

  • nie wymaga uruchamiania oprogramowania
  • wykonywane jest przed kompilacją
  • wyszukuje głównie nieścisłości, luki
  • wymaga specjalnych procesów i list kontrolnych
  • koszt odnajdywania nieprawidłowości i ich korekty są stosunkowo niewielkie

Testowanie dynamiczne:

  • wymaga uruchomienia programu; 
  • wyszukuje głównie awarie;
  • wykonywane jest po kompilacji kodu;
  • wymaga przypadków testowych;
  • koszt znajdowania i naprawy błędów jest wyższy

Sposoby testowania statycznego

Statyczne techniki testowania nie uruchamiają testowanego oprogramowania. Mogą być one wykonywane na dwa sposoby: ręczne (przeglądy) i automatyczne (analiza statyczna).

Przeglądy wykonywane są w celu odnalezienia defektów, problemów i niejasności w dokumentach takich jak m.in. wymagania. Odgrywają one znaczącą rolę w testach statycznych, gdyż dzięki nim wykryte mogą być potencjalne problemy na późniejszych etapach cyklu życia oprogramowania. Do innych korzyści przeglądów, zaliczyć można też: poprawę produktywności rozwoju oprogramowania, redukcja czasu potrzebnego na tworzenie oprogramowania, zmniejszenie kosztów i czasu potrzebnego na testowanie, zminimalizowanie ilości błędów oraz lepsza komunikacja.

Analiza statyczna polega na testowaniu oprogramowania w celu znalezienia defektów strukturalnych, w kodzie stworzonym przez programistów, bez jego faktycznego wykonywania. Analiza statyczna jest zwykle przeprowadzana przez narzędzia i służy do wykrywania defektów takich jak: naruszenie standardów oprogramowania, nieprzestrzeganie standardów kodowania, naruszenia składni, nieużywanie zmiennych, zapisane, ale nieużywane kody itd. Na rynku dostępne są narzędzia pomagające m.in. w statycznej analizie kodu, analizie struktur i zależności, obliczaniu metryk takich jak np. poziom zagnieżdżenia czy  złożoność cyklomatyczna, które zmuszają programistów do przestrzegania określonych standardów kodowania i znacznie pomagają w analizie statycznej.

Proces przeglądu w testowaniu statycznym i jego fazy

Przeglądy mogą występować w różnych formach — od nieoficjalnych aż po bardzo sformalizowane. Oficjalność procesu zależy od wielu czynników, takich jak np.: legalne bądź uregulowane wymagania, dojrzałość procesu oprogramowania czy konieczności przeprowadzenia audytu. Forma przeglądu zależna jest także od ustalonych celów, które ma spełnić (np. odnalezienie defektów). Poniżej przedstawiamy główne fazy, na które składa się przegląd:

  • planowanie — określenie i przypisanie obsługi, wyznaczenie ról, określenie warunków wejścia i wyjścia przy bardziej formalnych typach przeglądów (np. inspekcja), wyznaczenie części dokumentów wymagających sprawdzenia;
  • rozpoczęcie — dystrybucja dokumentów, nakreślenie uczestnikom zakresu prac, celów, dokumentów i procesów, a dla bardziej formalnych typów przeglądów dodatkowe sprawdzenie osiągnięcie kryterium wejścia;
  • indywidualne przygotowanie — praca wykonywana przez poszczególnych uczestników poprzedzająca spotkanie przeglądowe, określenie ewentualnych błędów, zanotowanie pytań i komentarzy;
  • spotkanie przeglądowe — dyskusja bądź rejestracja, zakończona dokumentem zawierającym dokładne podsumowanie wykonanych prac. Uczestnicy mogą podzielić się radami dotyczącymi radzenia sobie z błędami oraz podjąć decyzje odnośnie obecnych defektów;
  • poprawki — korygowanie znalezionych błędów, wykonywane z reguły przez autora;
  • kontynuacja — sprawdzenie, czy wskazane defekty zostały skorygowane bądź ocenione, zbieranie metryk, a przy bardziej formalnych typach przeglądów dodatkowe sprawdzenie kryterium wyjścia.

Role i odpowiedzialność podczas przeglądów

Poniżej przedstawiamy typowe role i zakresy obowiązków uczestników przeprowadzających przeglądy:

  • kierownik — to on podejmuje decyzję o rozpoczęciu przeglądu, wyznacza na niego czas w projekcie oraz decyduje czy cel przeglądu został osiągnięty;
  • moderator — jest osobą prowadzącą przegląd dokumentacji, planowanie prac oraz prowadzenie spotkania. W niektórych przypadkach może także pełnić rolę mediatora grupy i głównej osoby wspierającej sukces przeglądu;
  • autor — osoba odpowiedzialna za dokumenty, które podlegać mają przeglądowi;
  • przeglądający — zwani też sprawdzającymi bądź inspektorami, to osoby posiadające zazwyczaj specjalistyczne, biznesowe bądź techniczne przygotowanie. Po odpowiednim przygotowaniu identyfikują i opisują np. defekty w przeglądanym produkcie. Przeglądający powinni być dobrani w taki sposób, aby pełnić różne role w procesie przeglądu, reprezentować różną perspektywę i brać udział w spotkaniach przeglądowych;
  • zapisujący — jest osobą dokumentującą wszelkie problemy, sugestie i pomysły poruszone podczas spotkania.

Co musi zawierać skuteczny przegląd?

Do przeprowadzenia skutecznego przeglądu niezbędne jest zadbanie o kilka kluczowych kwestii. Należą do nich:

  • skrupulatnie określone cele, które spełnić ma przegląd;
  • odpowiednio dobrani i wykwalifikowani uczestnicy, którzy są zaangażowani w cele przeglądu;
  • odpowiednie dopasowanie technik przeglądu do poziomu uczestników oraz typu oprogramowania;
  • wzięcie pod uwagę czynników ludzkich i psychologicznych oraz stworzenie przestrzeni, gdzie wszyscy uczestnicy mogą się rozwijać i zdobywać cenne doświadczenie;
  • mile widziane jest wyłapywanie błędów i informowanie o zaistniałych defektach;
  • uczestnicy przeglądu powinni posiadać chęć rozwoju, nauki nowych rzeczy i poczucia pracy dla osiągnięcia wspólnych celów;
  • lista kontrolna powinna zawierać punkty niezbędne w procesie usprawnienia identyfikacji błędów;
  • kierownictwo powinno cały czas aktywnie wspierać proces przeglądu.

Testowanie statyczne — rodzaje przeglądów

Przegląd pojedynczego dokumentu może być przeprowadzony więcej niż jeden raz. Gdy tak się stanie, kolejność przeglądów może się zmienić. Przykładowo inspekcje wymagań mogą nastąpić przed sprawdzeniem ich przez klienta, a nieoficjalne przeglądy mogą poprzedzić te techniczne. Do głównych celów, opcji i parametrów typowych przeglądów  należą:

  • nieformalne, czyli techniczne prowadzenie przeglądu projektów i kodu, niedefiniowany proces bądź programowanie w parach. Może być ono udokumentowane i różnić się w zależności od przydatności określonej przez przeglądającego. Jego głównym celem jest osiągnięcie korzyści przy niewielkim nakładzie finansowym.
  • inspekcja przygotowywana jest przez moderatora. Obejmuje sprawdzenie pełnionych ról, listę znalezisk (np. defektów), przygotowanie przed spotkaniem, zawiera metryki, a formalny proces oparty jest na zasadach wejścia i wyjścia oraz finalny proces sprawdzenia wykonania założeń spotkania i ewentualnego ulepszenia prac. Jej głównym celem jest znajdowanie defektów.
  • techniczne — są to udokumentowane i zdefiniowane procesy detekcji błędów i innych defektów, zawierający uwagi kolegów z zespołu oraz ekspertów technicznych. Mogą być one przeprowadzane bez obecności kierownictwa, ale najlepiej by przewodniczył im moderator. Może to być przygotowane spotkanie, lista punktów kontrolnych i raport po zakończeniu przeglądu. Głównymi celami są tutaj: dyskusja, rozwiązywanie technicznych problemów, wymiana pomysłów, sprawdzanie alternatyw oraz zgodności ze specyfikacją i standardami.

Zalety i wady testów statycznych

Do niewątpliwych zalet testów statycznych zaliczyć można: lepsza jakość produktu, zmniejszenie kosztów i wysiłku włożonego w naprawę błędów, gdyż identyfikowane są one już na wczesnych etapach SDLC. Ponadto dają one głębszy wgląd w oprogramowanie dla każdego członka zespołu. Pomimo wielu przedstawionych powyżej plusów, testy statyczne mają też swoje wady, na które składa się m.in. to, że wymagają wielu spotkań i dużej ilości dokumentacji. Zdarza się także, że niektóre narzędzia analityczne nie są kompatybilne ze wszystkimi językami oprogramowania.

Notatka o autorze:

Zajmuję się testowaniem, zabezpieczaniem i zapewnianiem jakości oprogramowania od ponad 13 lat. Rozpocząłem swoją karierę od testów manualnych i analizy biznesowo-technicznej. Obecnie prowadzę firmę Quality Island, która zajmuje się szeroko pojętym testowaniem oprogramowania oraz szkoleniami dla przyszłych i obecnych testerów oprogramowania. Moją specjalnością są testy automatyczne aplikacji webowych oraz budowa procesów automatyzacji i robotyzacji. Od 8 lat prowadzę aktywnie szkolenia oraz konsultacje z tych tematów i wykonuję zlecenia dla firm trzecich jako konsultant, ekspert oraz audytor. Współpracuję również z firmami jako osoba do rekrutacji i weryfikacji technicznych. Interesują mnie głównie tematy związane z architekturą IT oraz zagadnienia DevOps/TestOps, ponieważ ściśle wiążą się z zapewnianiem jakości oprogramowania.

 

Tomasz Stelmach

CEO&Founder

 

0 komentarzy

Wyślij komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *