Eksplorowanie testowania shift-left
Testowanie w zarządzaniu cyklem życia aplikacji jest niezbędne do zmaksymalizowania jakości kodu i zminimalizowania ryzyka operacyjnego związanego z wdrażaniem i aktualizowaniem oprogramowania. Termin shift-left w tym kontekście wyraża ideę przenoszenia działań testowych możliwie jak najwcześniej w fazie rozwojowej. Organizacja w naszym przykładowym scenariuszu powinna rozważyć uwzględnienie tego podejścia do strategii DevOps, aby zminimalizować bieżące problemy z zabezpieczeniami i stabilnością. W tej lekcji przejrzyj różne typy testów, które można zaimplementować w ten sposób, a następnie zbadaj ich metody implementacji.
Jakie testy powinny być częścią testowania shift-left?
Programowanie oprogramowania obejmuje szeroką gamę typów testów, ale są to między innymi następujące elementy:
Testy jednostkowe: te testy koncentrują się na najmniejszych testowalnych częściach kodu aplikacji, takich jak poszczególne funkcje lub metody. Celem jest ustalenie, czy każda jednostka kodu może pomyślnie wykonać jego zamierzone działanie w izolacji od pozostałej bazy kodu i zależności zewnętrznych. Takie testy powinny być w pełni zautomatyzowane, szybkie (zakończone w ciągu 30 sekund) i zapewnić pełne pokrycie kodu (co w zasadzie oznacza, że wszystkie testy jednostkowe powinny wspólnie testować całą bazę kodu). Testowanie jednostkowe jest odpowiednie dla podejścia shift-left. Zalecamy zastosowanie go do całego kodu na wczesnym etapie cyklu programowania, najlepiej na początku fazy programowania.
Testy dymne: Testy te oceniają podstawowe funkcje aplikacji w środowisku testowym. Podczas testowania rzeczywistej aplikacji (zamiast poszczególnych, izolowanych składników, jak to robią testy jednostkowe), ich celem jest ustalenie, czy kompilacja lub wdrożenie aplikacji jest wystarczająco stabilna, aby zagwarantować bardziej szczegółowe testowanie. Nie weryfikują jednak współdziałania między aplikacjami. Podobnie jak w przypadku testów jednostkowych, powinny one być w pełni zautomatyzowane i stosunkowo szybkie (interakcja z użytkownikiem może być symulowana przy użyciu narzędzi automatyzacji przeglądarki i struktur automatyzacji interfejsu użytkownika). Termin test dymu ma na celu przekazanie idei dymu wskazującego na poważny problem (ogień), który należy rozwiązać tak szybko, jak to możliwe. Testy dymne powinny być również wdrażane na wczesnym etapie cyklu rozwoju, najlepiej, gdy tylko wersja oprogramowania zapewniająca jego podstawowe funkcje jest dostępna. Dotyczy to zarówno faz kompilacji aplikacji, jak i wdrażania.
Testy integracji: te testy weryfikują interakcję między różnymi składnikami aplikacji. W przeciwieństwie do testów jednostkowych, ich ukończenie może zająć dużo czasu. Dłuższy czas trwania tych testów jest często używany jako argument do uruchamiania ich na wczesnym etapie cyklu tworzenia oprogramowania. Ogólnie rzecz biorąc, należy rozważyć testy integracyjne w scenariuszach, dla których testy jednostkowe lub dymne nie są odpowiednie. Zaleca się jednak zaplanowanie ich wykonywania w regularnych odstępach czasu. Takie podejście zapewnia rozsądny kompromis między potencjalnym opóźnieniem w wykrywaniu problemów z integracją a dodatkowym czasem oczekiwania wymaganym do ich ukończenia.
Testy akceptacyjnych: Te testy określają, czy produkt oprogramowania spełnia wymagania biznesowe i jest gotowy do dostarczenia do swoich klientów. Testowanie akceptacyjne nie jest odpowiednie dla strategii zmiany w lewo, ale może być możliwe uwzględnienie niektórych elementów na wczesnym etapie cyklu tworzenia oprogramowania. Na przykład kryteria akceptacji i scenariusze użytkowników, które są istotnymi składnikami testowania akceptacyjnego, powinny zostać wprowadzone na wczesnym etapie procesu programowania. Ułatwia to współpracę między zespołami deweloperów, właścicielami produktów i uczestnikami projektu. Ponadto użytkownicy oprogramowania i uczestnicy projektu powinni być zaangażowani we wcześniejsze fazy testowania, aby podzielić się swoją opinią. Może to obejmować użycie takich metod, jak testowanie alfa lub beta, testowanie użyteczności lub wczesne wersje, przed formalnym testowaniem akceptacyjnym.