Jak ulepszyć CI / CD za pomocą testów z przesunięciem w lewo

Testowanie aplikacji było technicznie wymagającym, ograniczonym czasowo działaniem zaplanowanym na dni lub tygodnie przed wydaniem aplikacji. Zespoły programistyczne otrzymały swobodę programowania do jedenastej godziny, a testerzy, którzy większość swojej pracy wykonywali ręcznie, nie mieli innego wyboru, jak tylko zadowolić się poświęconym im czasem. W rezultacie wiele aplikacji przeszło testy niespełniające standardów, a zespoły technologiczne zostały zmuszone do reagowania na problemy produkcyjne i usterki eskalowane przez użytkowników końcowych i systemy monitorowania aplikacji.

Praktyki ciągłej integracji DevOps, struktury testowania jednostkowego i praktyki automatyzacji testów zmieniły ten paradygmat. Zamiast sprawdzania jakości na końcu procesu programowania, wiele praktyk testowych jest teraz uruchamianych i w pełni wykonywanych podczas kodowania, integracji i wdrażania. Zespoły deweloperskie i zwinne automatyzują skrypty testowe, a potoki ciągłej integracji / ciągłego wdrażania wzywają do uruchomienia testów na etapie integracji kodu lub dostarczania. W rezultacie programiści są ostrzegani, gdy zmiany w kodzie przerywają kompilację i mogą podjąć natychmiastowe kroki w celu rozwiązania zgłoszonego problemu.

Automatyzacja testowania i integracja skryptów testowych z potokami CI / CD jest znana jako testowanie z przesunięciem w lewo. Oznacza to, że więcej praktyk zapewniania jakości można zastosować w fazie rozwoju, aby wykryć problemy na wcześniejszym etapie publikacji. Automatyzacja testów jest jednym z priorytetów przed wdrożeniem dla zespołów zwinnych i deweloperskich, które chcą zwiększyć częstotliwość wdrażania.

Przy wprowadzeniu nowej funkcjonalności skonstruowane skrypty testowe sprawdzają nowe możliwości. Te testy można następnie zautomatyzować i uwzględnić w krokach kompilacji lub wdrażania. Zamiast zlecać inżynierom ds. Kontroli jakości wykonywanie testów regresji na końcu procesu wydania, wiele z tych testów można uruchomić i zweryfikować w ramach prac rozwojowych. Te testy przesuwają się w lewo od zakończenia procesu wydawania do wcześniejszych faz rozwoju i kodowania.

Testowanie z przesunięciem w lewo umożliwia zespołom zwinnym zaangażowanie w jakość

Testowanie z przesunięciem w lewo nie tylko zwiększa wydajność i poprawia jakość, ale także tworzy znaczącą zmianę kulturową w zwinnym procesie rozwoju.

Niektóre zespoły programistyczne postrzegają zapewnienie jakości i testowanie jako barierę w dostarczeniu kodu do produkcji. Po ciężkiej pracy związanej z satysfakcją właścicieli produktów zwinnych i ukończeniu kodu, członkowie zespołu ds. Kontroli jakości identyfikują listę błędów wymagających naprawy. Jeśli kontrola jakości znajdzie dużo błędów, może to wpłynąć na harmonogram wydania, aby je naprawić. Jeszcze gorzej jest, gdy istotne sekcje kodu wymagają przeprojektowania, ponieważ wady ujawniają problemy z logiką, bezpieczeństwem lub wydajnością. W tym scenariuszu programiści i inżynierowie ds. Zapewnienia jakości mogą należeć do tego samego zespołu zwinnego, ale nie działają jako zespół.

Testowanie z przesunięciem w lewo umożliwia zespołom zwinnym przeniesienie odpowiedzialności za jakość na cały zespół programistów i testerów. Gdy testowanie jest częścią potoku CI / CD, zapewnia programistom lepszą okazję do rozwiązania problemów z jakością w momencie, gdy pracują nad odpowiednim kodem. Potok CI / CD ostrzega dewelopera o nieudanej kompilacji, a większość samoorganizujących się zespołów programistycznych wymaga natychmiastowego rozwiązania tych problemów.

Testowanie z przesunięciem w lewo zapewnia również programistom i inżynierom kontroli jakości możliwości automatyzacji większej liczby testów. Najlepszą praktyką jest, aby zespoły decydowały, kto wdraża automatyzację, w zależności od typów testów wymaganych dla opracowanej funkcjonalności. Na przykład programiści są często odpowiedzialni za automatyzację testów jednostkowych i testów API, ale inżynierowie automatyzacji zapewniania jakości często opracowują kompleksowe testy doświadczenia użytkownika i testy transakcji, które symulują wieloetapowe wywołania API do wielu usług.

Kiedy stosować testowanie z przesunięciem w lewo

Testowanie z przesunięciem w lewo działa najlepiej w przypadku testów atomowych na poziomie jednostki, które mają krótkie czasy wykonania. Ważne jest, aby testy były zautomatyzowane w potoku CI / CD i były uruchamiane za każdym razem, gdy programiści uruchamiają kompilację, wykonują się szybko i nie spowalniają procesów kompilacji.

Bardziej złożone i czasochłonne testy, takie jak kompleksowe testy doświadczenia użytkownika, testy transakcji, statyczna analiza kodu i testy bezpieczeństwa, często działają lepiej poza potokami CI / CD i według codziennych lub częstszych harmonogramów. Testy te nadal dostarczają programistom wczesnych informacji zwrotnych na temat problemów z jakością, ale są one zautomatyzowane poza CI / CD, aby uniknąć spowolnienia lub wąskiego gardła kompilacji.

Thomas J. Sweet, wiceprezes ds. Usług IT w GM Financial, podzielił się ze mną swoimi osobistymi spostrzeżeniami na temat ograniczeń strategii testowania z przesunięciem w lewo. Sugeruje: „Przesunięcie w lewo jest zawsze strategią, z wyjątkiem przeprowadzania testów integracyjnych na dostawach innych dostawców, ponieważ często nie masz dostępu do ich kodu źródłowego. Nawet jeśli masz aplikacje wewnętrzne ze starszymi architekturami monolitycznymi, możesz zacząć od wymuszenia podstawowych zasad ewidencjonowania, które wymagają przeglądu kodu i skanowania zabezpieczeń. Zgłoszenie należy odrzucić, jeśli skanowanie zawiera istotne ostrzeżenia i niepowodzenia. ”

Jednym z potencjalnych rozwiązań dla dalszych testów z partnerami integracyjnymi jest wdrożenie wirtualizacji usług. Technika ta umożliwia zespołom programistów symulację odpowiedzi systemu podrzędnego na różne dane wejściowe. Działa dobrze, gdy dalsze systemy są dobrze zdefiniowane. Narzędzia firm Micro Focus, Tricentis i innych umożliwiają taką możliwość.

Rob Pociluk, bardzo doświadczony menedżer ds. Zapewniania jakości, jest zagorzałym zwolennikiem testowania w lewo w programowaniu zwinnym. „Gotowość i możliwość testowania małych fragmentów kodu zapewnia elastyczność i ciągłość kontroli jakości podczas przebiegu sprintu. Zespoły powinny nadal wystrzegać się używania klawisza shift-left zbyt często, ponieważ możesz stracić cel samego kodu ”.

Tak więc, nawet jeśli zespoły w pełni wykorzystują testowanie z przesunięciem w lewo, istnieją dobre powody, aby nadal planować okno testowe dla kompletnej kompilacji kodu, która ma zostać wydana. Zapewnia wykonanie wszystkich testów automatycznych na ostatecznej kompilacji, ale także umożliwia planowanie dodatkowych testów, które wymagają w pełni funkcjonującego systemu.

Jednym z takich testów jest UAT (test akceptacji użytkownika), w ramach którego wybrani użytkownicy końcowi i eksperci merytoryczni weryfikują i przekazują informacje zwrotne. Niektóre UAT można wykonać podczas programowania, ale może nie być łatwo skłonić ludzi do częstego wykonywania tych testów lub gdy funkcjonalność nie jest w pełni gotowa.

Warunki wstępne do strategii testowania z przesunięciem w lewo

Testowanie z przesunięciem w lewo to rosnąca praktyka DevOps, ale ma swoje wymagania wstępne i inwestycje z góry. Wymagane są pewne podstawowe możliwości i praktyki.

  • Do obsługi liczby kompilacji i testów, które działają jednocześnie, potrzebne są wystarczające możliwości testowania i odpowiednie środowiska.
  • Zespoły zwinne wymagają zestawu narzędzi do testowania produktów, które można łatwo zintegrować z potokami CI / CD i narzędziami do planowania zadań oraz które mogą weryfikować funkcjonalność, jakość kodu, bezpieczeństwo i wydajność.
  • Architekci, specjaliści infosec, kierownicy kontroli jakości i inni starsi członkowie organizacji powinni ustanowić standardy testowania i cele poziomu usług, które tworzą domyślne kryteria akceptacji.
  • Gdy aplikacje wymagają danych wejściowych użytkownika, zespoły testowe potrzebują wystarczających danych testowych i wzorców, aby zweryfikować wystarczającą liczbę person, przypadków użycia i wzorców wejściowych.
  • Przy zaangażowaniu sprintu lub wcześniej, zespoły scrumowe, w tym inżynierowie automatyzacji testów QA, powinni ustalić strategię testowania dotyczącą testowanych możliwości, typów testów wdrażanych, aktualizowanych procesów automatyzacji i twórców testów.
  • Zespoły Devops powinny mierzyć czas trwania przebiegów potoków CI / CD i oznaczać, gdy zautomatyzowane etapy testowania wpływają na produktywność. Zespoły Devops często wymagają dodatkowych harmonogramów testowania poza potokami CI / CD, aby wykonać dłużej działające testy.
  • Zespoły powinny regularnie omawiać luki w swoich automatycznych testach, zwłaszcza walidacje, które wymagają ekspertów merytorycznych, UAT lub testowania z partnerami. Jeśli zespoły zwinne nie mogą rozwiązać tych luk za pomocą automatyzacji, cykle wydawania powinny uwzględniać koszty ogólne, aby zmniejszyć ryzyko i ukończyć te testy.

Wreszcie zespoły zwinne i organizacje DevOps powinny regularnie mierzyć i omawiać pokrycie testów. Stosowanie strategii testowania z przesunięciem w lewo nie działa, jeśli zespoły programistyczne i inżynierowie automatyzacji jakości w rzeczywistości nie wdrażają, nie automatyzują i nie integrują wystarczających testów, aby wykryć problemy i rozwiązać ryzyko.

Przyspieszenie cykli wydawania lub umożliwienie ciągłego dostarczania bez wystarczającej automatyzacji testów może skutkować znacznymi problemami z jakością, które pogarszają wrażenia użytkowników końcowych. Zespoły programistów zwinnych, które zbyt często publikują wersje, zajmują się problemami i usterkami produkcyjnymi, zamiast inwestować w większą i lepszą automatyzację.