Rola testera w metodyce DevOps

Tym razem wpis jest gościnny, zostałem poproszony przez Szefową tego bloga o napisanie krótkiego posta o tym jaka jest rola testera w metodyce DevOps.

Zacznijmy od podstaw: czym w ogóle jest ten cały DevOps?

Jeśli zapytamy 2 osób o to czym jest DevOps to dostaniemy 3 różne odpowiedzi. Każdy rozumie ten termin trochę inaczej i w innych aspektach.

Według wikipedii to metodyka mająca na celu zwiększenie współpracy poprzez zacieśnianie więzów i współpracy pomiędzy departamentami DEV, IT Ops, QA (i wielu innych)

Do mnie przemawia bardziej definicja Donovana Browna, który jest Principal DevOps Managerem w Microsofcie.

DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.

Proste prawda? Zadziwiające jak wielu z nas ma problem, żeby to zrozumieć i potem wykorzystać w praktyce… Kluczowy jest tu ten kawałek o zadowoleniu naszego użytkownika / klienta!

Większości ludzi, którzy słyszą hasło DevOps wydaje się, że nasza praca wygląda mniej więcej tak:

 

Czemu? Bo większości ludzi DevOps kojarzy się z automatyzacją i kilkoma magicznymi hasłami (m.in. infrastructure as a code, orchestration, containers – chef, puppet, ansible, docker, kubernetes).

Oczywiście jest to prawda, bo jednym z zadań DevOpsów jest automatyzacja i optymalizacja procesów, z którymi mamy do czynienia. Natomiast fundamentalne pytanie brzmi — czy jest to nasze jedyne zadanie? Czy DevOps ma się zajmować jedynie narzędziami i technologiami?  Według mnie nie, w mojej definicji DevOps = Ludzie + Kultura + Współpraca (+na końcu narzędzia).

Oczywiście można zautomatyzować wszystko — testy, proces budowania aplikacji, integracje aplikacji, spin-off nowych środowisk, deploymenty aplikacji, testy bezpieczeństwa itd… Ale czy to oznacza, że mamy DevOps u siebie w organizacji? Oczywiście, że nie! Mamy wysoki poziom automatyzacji, ale z DevOpsami ma to tyle wspólnego ogórek z wasabi…

Istotą DevOpsów jest ścisła współpraca pomiędzy wszystkimi zespołami zaangażowanymi w dany projekt. Istotą DevOpsów jest również usuwanie niepotrzebnych barier pomiędzy zespołami — zespoły powinny być interdyscyplinarne i być w stanie blisko ze sobą współpracować.

 

Jednak jaka w tym wszystkim jest rola testera?

W „nowej rzeczywistości” jest kilka ról, w których testerzy mogą się odnaleźć:

  • zaangażowanie na najwcześniejszym etapie – ustalania wymagań dotyczących projektów (testowalność wymagań, definition of done, kryteria wydajności, bezpieczeństwa)
  • automatyzacja przypadków testowych – nie tylko funkcjonalnych e2e, ale również integracyjnych czy wydajnościowych
  • zaangażowanie w procesy continuous everything* (integration, deployments, delivery, testing)
  • testy eksploracyjne

Testowalność wymagań

Najważniejszą rzeczą dotyczącą zmian kulturowych proponowanych przez DevOps jest unikanie „przekazywań” — „no handoffs” (wiedzy, informacji, odpowiedzialności, obowiązków — dopowiedzcie sobie wszelkie inne handoffy, które wam przyjdą do głowy). Powinno zależeć nam na tym, aby na końcu procesu klient był maksymalnie zadowolony i dostał produkt / usługę, która spełnia jego oczekiwania — dlatego powinniśmy być obecni już na etapie ustalania wymagań — właśnie po to, żeby się upewnić, że wymagania, które ustalamy z klientem, są możliwe do przetestowania, czy mają jasno określone kryteria zakończenia. Czy w przypadku aplikacji webowych mamy informacje o wydajności danych funkcjonalności / operacji dostępnych dla użytkownika itp?

Automatyzacja przypadków testowych

Ten punkt wydaje się najbardziej banalny – niestety też jest kilka „ale” o których trzeba pamiętać.

Po pierwsze – automatyzacja przypadków testowych to proces a nie zadanie. Nie można tego potraktować trybem fire & forget — jeśli aplikacja żyje i się zmienia to obowiązkowo, muszą zmieniać się również przypadki testowe. Po drugie — ile z Was pisze automaty do integracji aplikacji? Do takiej prawdziwej integracji z prawdziwymi systemami — a nie do mockupów które będą zawsze w ten sam sposób odpowiadać? Czy wasze aplikacje są testowane wydajnościowo regularnie, czy od wielkiego dzwonu? Tego typu pytań jest wiele — niestety nie ma jednej dobrej odpowiedzi na to pytanie, bo zależy to od wymagań aplikacji, ale często się zdarza, że aplikacje mają pokryte automatami jedynie podstawowe ścieżki lub smoke testy — a to niestety za mało.

Continuous everything*

Ten punkt może być trochę mylący — bo nie chodzi mi o to, że testerzy muszą znać się na jenkinsie, deploymentach, testowaniu, przygotowywaniu releasów — chodzi mi o to, znowu — aby byli obecni na każdym etapie tych procesów:

  • 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ć (brak danych, problemy sieciowe, źle zbudowane artefakty, źle przygotowane środowisko…)

Testy eksploracyjne

To w zasadzie najciekawszy temat — jeśli mamy aplikacje, która jest na tyle stabilna, że pokrycie ścieżek automatami testowymi jest satysfakcjonujące dla nas i dla klienta — możemy się skupić na tej kreatywnej części pracy — szukaniu nowych błędów / pominiętych ścieżek / walidacji itp. Taka jest idea automatyzacji — uwolnić ludzi od powtarzalnych czynności i dać im możliwość skupić się na kreatywnych i ciekawych dla nich zadaniach.

Podsumowanie

To o czym napisałem powyżej to oczywiście tylko i wyłącznie moje zdanie i moje spojrzenie na rolę testerów w DevOps. Poparte jest wieloletnim doświadczeniem i obserwacjami z różnych organizacji, w których miałem przyjemność pracować. Nie zachęcam, żebyście traktowali to jako przepis na sukces — bo takiego złotego środka w DevOps nie ma. Spójrzcie na swoją organizację i zastanówcie się, w jaki sposób można zaimplementować ten wzór:

DevOps = Ludzie + Kultura + Współpraca (+na końcu narzędzia)

 

Powodzenia,

Piotr Szulawski, DevOps Team Lead @ DXC Technology

Napisz komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Solve : *
29 − 5 =