Mantra DevOps

 

Dwa tygodnie w części I tego wpisu temu staraliśmy się ogólnie nakreślić, czym jest podejście Shift-left, jaki ma związek z modelem kaskadowym i jakie kluczowe kwestie składają się na tę koncepcję. Tym razem proponujemy wiedzę trochę bardziej praktyczną taką ready-to-use. Wypunktujemy co każdy tester i każda testerka powinni zmienić w swojej pracy, by przybliżyć się do koncepcji „przesunięcia w lewo” oraz (co chyba najważniejsze 😉 ) przedstawimy zalety i korzyści wynikające ze stosowania tej metody.

Co testerzy powinni robić inaczej w podejściu Shift-left

  • Zespoły testerskie muszą z wyprzedzeniem angażować się w proces tworzenia produktu na znacznie wcześniejszych etapach, najlepiej od momentu rozpoczęcia projektu. W ten sposób mają szansę na szybkie rozwinięcie współpracy z innymi członkami zespołu (np. programistami) oraz na dostarczenie użytecznych danych wejściowych na właściwie każdym etapie cyklu życia produktu. Pozwoli to także na uniknięcie defektu w przyszłości, na późniejszych etapach tworzenia.
  • Zespół testerski powinien współpracować z zespołem biznesowym oraz operacyjnym, by znać plan tworzenia produktu. Powinien jasno przedstawić swoje wymogi i zaangażować się w proces planowania potrzeb. Może zaistnieć konieczność np. zwiększania zasobów technicznych w konkretnym projekcie, przeprowadzenia szkolenia czy zatrudnienia nowej osoby.
  • Testerzy powinni angażować się w komunikację ze wszystkimi interesariuszami biznesowymi już na wczesnym etapie rozwoju produktu, aby mieć dokładny jego obraz końcowy, zaprojektować ujednoliconą strategię testowania, zaplanować zoptymalizowany wysiłek testowy, przeanalizować zależności od: środowisk testowych, stron trzecich, numerów pośrednich itp. Pomoże to także przygotować solidną strategię i strukturę automatyzacji oraz zbudować skuteczny plan zarządzania danymi testowymi.
  • Niezbędna jest współpraca z resztą zespołu, przy jednoczesnym zapewnieniu kierownictwa testowego i wskazówek dla zespołu. Równolegle grupa testerów powinna mieć na uwadze długoterminową wizję produktu, a nie brać tylko odpowiedzialności za czynności testowe.
  • Wymagania są kluczem i podstawą sukcesu każdej strategii, a dobrze określone definiują sukces projektu. Podczas fazy planowania wymagań testerzy muszą przejrzeć i przeanalizować kryteria dotyczące dowolnej niejednoznaczności, większej jasności, kompletności, możliwości testowania, definicji kryteriów akceptacji itp. Należy również zidentyfikować brakujące wymagania, jeśli takie istnieją, zrozumieć zależności i strategie wdrażania.
  • Testerzy powinni regularnie uczestniczyć w spotkaniach poświęconych przeglądowi projektu, zrozumieć koncepcję produktu i jego architekturę. Dzięki posiadanej wiedzy powinni sprawnie identyfikować wady projektu, sugerować alternatywne opcje, identyfikować luki w zabezpieczeniach i tworzyć scenariusze testowe.
  • Powinni przeprowadzić testy statyczne (przeglądy) z dużym wyprzedzeniem i przekazać dalej informacje zwrotne na temat kluczowych dokumentów projektowych. Pozwoli to zapobiec wadom w oprogramowaniu i zwiększyć jego efektywność w późniejszym czasie.
  • Zespół testerski powinien współpracować z teamem projektowym i programistycznym w zakresie dostarczania scenariuszy testowych z wyprzedzeniem, by opracować kod i rozwiązania wszystkich możliwych scenariuszy w czasie rzeczywistym.

Kierunek Waterfall.

Angie Jones, inżynierka automatyzacji, prowadząca konsultacje w tym zakresie, by zwiększyć zaangażowanie testerów w całość projektu, zaleca im, by robili to, co wiedzą, że jest właściwe. Obranie metody Shift-left jest z pewnością korzystnym posunięciem, ale testerzy wiedzą lepiej, niż ktokolwiek inny, które i w jaki sposób ich umiejętności okażą się użyteczne przy danym projekcie. Jones zachęca testerów do brania czynnego udziału w meet-upach: „Nie siedźcie w milczeniu” mówi w wywiadzie „It’s Time for Testers to Own the Shift-left Narrative” . Nakłania do wykorzystywania swoich umiejętności do przewidzenia potencjalnych obszarów problematycznych i niebania się ich wskazania. „Gdy testerzy zaczną w ten sposób się angażować, stają się nieocenionymi członkami zespołu” konkluduje Jones.

Cała zasada koncepcji Shift-left dla testerów polega na znalezieniu wad jak najwcześniej za pomocą wszelkich możliwych środków.

Zalety Shift-left Testing a Manifest Agile

Podejście Shift-left funkcjonuje na podstawie Manifestu Agile i wyróżnia się następującymi korzyściami:

  • Osoby i interakcje nad procesami i narzędziami.
  • Pracujące oprogramowanie nad obszerną dokumentacją.
  • Współpraca z klientem nad negocjacją umowy.
  • Odpowiadanie na zmiany w następstwie planu.

Wartości wymienione po prawej stronie z pewnością nie są nam obce, jednak w podejściu Shift-left bardziej cenione są hasła zapisane po lewej, które obszerniej opisujemy poniżej.

6 powodów, by przesunąć proces testowy w lewo:

    1. Wyższa jakość kodu z mniejszą ilością błędów

Metoda ta powoduje, że więcej testów jest uruchamianych, przeprowadzanych oraz następuje to częściej, w porównaniu do standardowego podejścia. Dzięki ciągłemu sprawdzaniu systemu pod kątem defektów i przeprowadzaniu testów każdej kompilacji nie tylko zespół testerski, ale cały team ciągle są ostrzegani o pojawiających się słabych punktach. W rezultacie można zareagować szybciej i natychmiast naprawić błąd. Zapewnia to wyższą jakość kodu i znacznie lepszą wydajność systemu.

Przy tej metodzie pracy zespół testerki nie musi martwić się o błędy z poprzedniej wersji. Te zostały już naprawione lub rozwiązane, dzięki czemu można skupić się na zadaniach bieżących i pracować efektywniej.

    1. Częstsze releasy

Zamiast najpierw opracowywać testy, czekać na zespół QA, by je przeprowadził, spierać się z QA o wyniki tych testów, naprawiać kod, ponownie czekać na wyniki testu, wpaść na to, że zapomniało się poprawić ważnej części kodu, ponownie wysłać kod, czekać na testy, naprawić kod po raz ostatni, tylko po to, aby zdać sobie sprawę, że koliduje on z kodem innego programisty i nie można go publikować, warto zastanowić się na znacznie szybszą i efektywniejszą opcją.

Poprzez lepszą integrację testów z cyklem życia produktu, każdy fragment kodu jest natychmiast testowany. Po zatwierdzeniu kodu nowa wersja zostaje natychmiast wydana na korzyść klienta / użytkownika. Rozwiązanie to jest również korzystne dla programistów, dając im czyste konto do dalszej pracy. Jeśli defekt zostanie wykryty przez zespół testerski – nie ma problemu. Deweloper zostanie bezzwłocznie o błędzie w kodzie poinformowany, może łatwo zidentyfikować problem i go naprawić. Naprawiony kod jest natychmiast testowany i publikowany.

Współpraca przy stole.

    1. Więcej współpracy

Członkowie całego zespołu będą bardziej współpracować przy opracowywaniu wspólnych funkcji produktu. Każdy programista będzie wprowadzał taki kod, aby ten zintegrował się z innymi. Będą także pracować razem nad odkryciem wad systemu, aby dowiedzieć się, jak naprawić błędy i wąskie gardła.

Poprawi się współpraca programistów z zespołem zarządzającym produktem. Natychmiastowe testy i ostrzeżenia o kodzie będą dokładnie odzwierciedlać działania każdego z członków zespołu. Pozwali to liderom np. Teamów programistycznych na wyznaczenie programistów do zadań dostosowanych do ich mocnych stron lub do obszarów, które wymagają poprawy.

Przesuwając swoje działania w lewo, zespoły widzą ogromne korzyści, takie jak znajdowanie błędów znacznie wcześniej, czasami, nawet zanim kod zostanie kiedykolwiek napisany. Skutkuje to wyższą jakością kodu i znacznie mniej kosztownym sposobem uzyskania takiego kodu.*

    1. Redukcja kosztów

Przesunięcie w lewo oznacza szybsze i bardziej zautomatyzowane testowanie, dzięki czemu ostateczny produkt jest lepszej jakości. Wszystkie wymienione elementy powyższego zdania są opłacalne dla firmy. Dzięki wyższemu stopniowi automatyzacji cały czas przeprowadzane są równoległe testy, a testerzy i programiści mogą skupić się na opracowywaniu nowego kodu zamiast na prozaicznych i wyczerpujących procesach. Jeśli testy przeprowadzane są w chmurze, oszczędza się także koszty infrastruktury.

    1. Zadowolenie klientów

Wyższa prędkość wydań z szybszymi naprawami i nowymi funkcjami zwiększa zadowolenie klientów, którzy pozostają z firmą, zamiast przenosić się do konkurencji. Są zadowoleni z wartości, jaką otrzymują z inwestycji. Metoda ta pozwala skupiać się na wymaganiach użytkowników i poprawić jakość ich obsługi.

    1. Elastyczności i Automatyzacja

Automatyzacja (która jest bardzo częstym rozwiązaniem przy metodzie Shift-left) banalnych zadań i konfigurowanie przejrzystych schematów testowych daje programistom i zespołom większą elastyczność podczas planowania i realizacji projektów. Zamiast poświęcania czasu pracy na oczekiwanie na przeprowadzanie testów, zautomatyzowane testy zapewniają szybkie odpowiedzi i gwarantują więcej czasu na inne zadania. Dzięki temu harmonogramy pracy są łatwiej dostosowywane. Ich elastyczność jest korzystna dla programistów i testerów, którzy wydajniej będą pracować bez stresu i nudy, dla menedżerów, którzy mogą przypisywać pracowników do innych projektów, które np. się opóźniają.

Wreszcie przesunięcie w lewo i automatyzacja zwiększają elastyczność produktu. Zapewniają więcej czasu na tworzenie nowych funkcji, na uzyskiwanie informacji zwrotnych od klientów i reagowanie na nie, na szybsze poprawki i wydania. Ma to zasadnicze znaczenie dla konkurencyjności na rynku, świadczenia najlepszych usług, przyciągania pracowników o najwyższych kwalifikacjach zawodowych i utrzymania bezpieczeństwa i jakości produktów.

Cała branża się zmienia, dlatego ważne jest, by przyjąć te zmiany i określić sposoby wykorzystania umiejętności zespołów w jak najefektywniejszy sposób.*

Koncepcja Shift-left przyniosła ogromną transformację i zmianę sposobu myślenia nie tylko o testowaniu, ale i o roli zespołów testerskich w całym projekcie. Przesunięcie procesu testowego w lewo skutkuje większym zaangażowaniem zespołów testerskich w cykl życia produktu. Wiąże się to z szeregiem korzyści, które ma szansę odnieść cała organizacja.

 

*Wszystkie cytaty oznaczone * pochodzą z wypowiedzi Angie Jones, z wywiadu It’s time for Testers to Own the Shift-left Narrative

5
  •  
    3
    Shares
  • 3
  •  
  •  
  •