Testowanie w DevOps Część II

Tagi: 0

W naszym lipcowym wpisie staraliśmy się przybliżyć wam ogólną charakterystykę metodyki DevOps. Uzbrojeni w taką podstawę teoretyczną, możemy przejść do obszaru ściślej związanego z tym, co nas najbardziej interesuje 😉

Dziś zapoznamy się z Continuous Testing; procesem bardzo charakterystycznym dla DevOps i zastanowimy się, jak w takiej sytuacji kształtuje się rola testera oprogramowania.

DevOps to nie tylko konkretna metodologia, czy zbiór wybranych narzędzi. DevOps to inicjatywa niwelująca bariery między Dev i Ops, by w ostatecznym rozrachunku zaspokoić potrzeby niezwykle dynamicznego rynku. Organizacje korzystające z DevOps reagują bardzo elastycznie na zmieniające się wymagania biznesowe. W takim modelu programiści płynnie integrują się z zespołem QA, testerami, analitykami biznesowymi i wszystkimi innymi specjalistami zaangażowanymi w projekt.

Wyróżnić można cztery podstawowe procesy w metodyce DevOps:

  • Continuous Integration (CI; nieustanna/ciągła integracja)
  • Continuous Delivery (CD; nieustanna/ciągła dostawa)
  • Continuous Testing (CT; nieustanne/ciągłe testowanie)
  • Continuous Monitoring (CM; nieustanne/ciągłe monitorowanie)

W DevOps testowanie nie stanowi ostatniego etapu przed wypuszczeniem produktu na rynek. Wręcz przeciwnie – to integralna część każdego z etapów tworzenia oprogramowania czy aplikacji. Programiści i inżynierowie otrzymują kod w środowisku odpowiednim do przeprowadzenia Continuous Integration oraz Continuous Delivery, dzięki czemu umożliwiają przeprowadzenie procesów Continuous TestingContinuous Monitoring, w których zespoły QA i testerskie mogą potwierdzić, że zbudowano odpowiedni kod, sprawdzając, czy działa zgodnie z założeniami projektowymi.

Darmowy ebook

Podstawowym zadaniem testerów staje się zatem dostosowanie ich scenariuszy testowych, procesów automatyzacji i przypadków testowych do sposobu działania DevOps. Należy ciągle monitorować, czy zmiany naniesione w kodzie działają zgodnie z założeniami i czy nie spowodowały uszkodzenia produktu, wpływając w niepożądany sposób na pozostałe funkcjonalności. Organizacja może zautomatyzować integrację, testowanie, dostarczanie i monitorowanie, ale musi to zrobić w sposób świadomy, inteligentny i dojrzały. Wyważona i rozsądna automatyzacja i organizacja testów, minimalizuje ryzyko chociażby powstania wąskich gardeł w przedsiębiorstwie.

Czym jest Continuous Testing

Nieustanne testowanie to proces przeprowadzania testów automatycznych jako części procesu dostarczania oprogramowania w celu uzyskania informacji zwrotnej na temat ryzyka biznesowego związanego z wydaniem oprogramowania tak szybko, jak to możliwe. CT przyczynia się do rozwoju i rozszerzenia zakresu zautomatyzowania testów, by sprostać rosnącej złożoności i szybkości ewolucji nowoczesnych aplikacji oraz tempu ich dostarczania.

Automatyzacja testów ma na celu stworzenie zestawu danych punktowych pozytywnych lub negatywnych (pass/fail) skorelowanych z historiami użytkowników lub wymaganiami aplikacji. Z kolei ciągłe testowanie koncentruje się na ryzyku biznesowym i zapewnia wgląd w to, czy produkt może zostać wydany. By to osiągnąć, należy przestać zadawać sobie pytanie „Czy skończyliśmy już testować?”, a zamiast tego zapytać „Czy produkt kandydujący do wypuszczenia na rynek ma akceptowalny poziom ryzyka biznesowego?”.

Continuous Testing Ciągłe Testowanie DevOps

Źródło: What is Continuous Testing.

Cechy Ciągłego Testowania według Tricentis

  • Podstawowym celem CT jest ocena poziomu ryzyka biznesowego
  • Nieustanne testowanie zapewnia natychmiastowy wgląd w to, czy produkt, który ma zostać wypuszczony na rynek, jest zbyt ryzykowny, by przejść przez proces jego dostarczania
  • Zakłada, że procesy testowe będą obecne na każdym poziomie cyklu życia produktu, a nie tylko na jego końcu
  • Wymaga stabilnego środowiska testowego z ważnymi danymi testowymi, które będą dostępne dla każdego testu
  • Nieustanne testowanie polega na wykonywaniu właściwego zestawu testów na właściwym etapie procesu dostawczego, bez tworzenia wąskiego gardła
  • Zapewnia zwroty, które dają podstawę do działania i są przydatne na każdym etapie procesu dostawy
  • Ocenia każdą warstwę nowoczesnej architektury oprogramowania na odpowiednim etapie procesu dostarczania
  • Obejmuje kompleksowe testy, które realistycznie oceniają wrażenia użytkownika końcowego na wszystkich powiązanych technologiach (frontend i backend)
  • Redukuje liczbę fałszywych trafień, nadając priorytety solidnym, elastycznym nowoczesnym strukturom testowym
  • CT polega na nieustannym przeglądaniu i optymalizacji zestawu testów w celu wyeliminowania nadmiarowości i maksymalizacji zasięgu ryzyka biznesowego

Ciągłe Testowanie to zmiana

Trudno nie zgodzić się z tym, że Agile i DevOps koncentrują się na transformacji, zmieniając ludzi, procesy i technologie, by dostarczyć innowacyjne oprogramowanie tak szybko, jak to tylko w danym momencie możliwe. Pomimo wszystkich tych zmian, jedna rzecz wydaje się niezmieniona: proces testowania oprogramowania. W Report: Testing Lags in Agile Development Shops czytamy, że z 70% organizacji, które przyjęły Agile, tylko 30% z nich automatyzowało testowanie. Badania Testing Trends in 2016: A Survey of Software Professionals wykazały natomiast, iż mimo że obecnie blisko 88% firm adaptuje Agile, tylko 26% z nich szeroko przyjęło automatyzację testów.

Świadczy to o tym, że procesy testowe utknęły w przeszłości, nawet gdy organizacje inwestują dużo czasu i wysiłku w transformację procesów rozwojowych, by sprostać dzisiejszym i przyszłym wymaganiom biznesowym.

Większość starszych narzędzi i procesów testowania oprogramowania nie nadaje się do Continuous Testing, których wymaga metodyka DevOps, ze względu na:

  • Długi czas wykonania – testy są czasochłonne, więc nie opłaca się uruchamiać całego zestawu testów regresji dla każdej wersji. Oznacza to, ze zespół nie otrzymuje natychmiastowej informacji zwrotnej na temat tego, czy produkt, który ma zostać wydany, jest zbyt ryzykowny, by przejść przez proces dostarczenia
  • Absorbujące utrzymanie – testy UI wymagają znacznej ewolucji, by dotrzymać kroku często zachodzącym zmianom charakterystycznym dla przyspieszonego procesu wypuszczania produktu na rynek. Taka sytuacja powoduje powolne, uciążliwe utrzymanie testów lub wstrzymanie prac związanych z automatyzacją
  • Niestabilność środowiska testowego –  często prowadzi do przekroczenia limitu czasu, niekompletnych testów, fałszywych alarmów lub niedokładnych wyników, uniemożliwiając dostarczenie szybkiej i jakościowej informacji zwrotnej wymaganej przy podejściu DevOps

Devops team

Rola testera w CT

W rzeczywistości pod znakiem DevOps testerzy mogą odnaleźć się w kilku rolach, a ich zadania nie muszą się ograniczać do analizy oprogramowania sensu stricto. Wręcz przeciwnie; DevOps zachęca do elastyczności i zwiększenia wszechstronności. Piotr Szulawski, DevOps Team Lead @ DXC Technology, w swoim tekście przedstawił parę propozycji na rozszerzenie zadań testera.

Tester oprogramowania świetnie może się sprawdzić już na bardzo wczesnym etapie cyklu życia produktu. Wytyczenie wymagań dotyczących projektu uwzględniając testowalność wymagań, definition of done, kryteria wydajności czy bezpieczeństwa, to świetna okazja, by podzielić się swoim doświadczeniem. W dalszym etapie może skupić się na automatyzacji przypadków testowych (np. integracyjnych czy wydajnościowych). Tester może zaangażować się właściwie w każdy proces spod znaku Continuous. Szulawski wymienia następujące podkreślając jednocześnie, że nie jest zadaniem testera znanie się na wszystkim i na każdym procesie – chodzi o obecność na każdym z etapów cyklu życia produktu:

  • Build – wsparcie testami automatycznymi
  • Tworzenie środowisk — tutaj testerzy mogą zarówno być doradcami (jakich komponentów powinniśmy użyć, w jakich wersjach, jakimi danymi zasilić środowisko), jak i zarządcami (jeśli środowisko jest konfigurowane za pomocą ansibla/chefa/puppeta, to sami mogą zarządzać definicją środowisk i odpowiednim wersjonowaniem komponentów)
  • Deployment na środowiska testowe – automaty integracyjne, wydajnościowe, integralność danych
  • Releasy — testy eksploracyjne, pomoc w diagnozowaniu „znanych problemów”, które mogą się zawsze pojawić (np. brak danych, problemy sieciowe, źle zbudowane artefakty, źle przygotowane środowisko…)

Jak widzicie, zadań dla testera oprogramowania w DevOps jest wiele i tylko od waszej kreatywności, inicjatywy oraz środowiska zależy od którego etapu cyklu życia produktu będzie w niego zaangażowani. Continuous Testing wymaga nie tylko zacięcia i szybkości działania, ale przede wszystkim umiejętności komunikacji. DevOps to przede wszystkim ludzie, dopiero potem narzędzia.

DYSKUSJA

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

wypróbuj

Zarejestruj się i zacznij działać!