Czy znasz Agile Testing Life Cycle (ATLC)? Jest to proces stosowany przez zespoły programistów w celu zapewnienia prawidłowego i skutecznego testowania ich aplikacji.
Ten post przeprowadzi Cię przez wszystko, co musisz wiedzieć o ATLC, w tym o jego zaletach, krokach związanych z procesem, planowaniu praktycznej strategii testowania, wykonywaniu testów opartych na zbieraniu wymagań i śledzeniu błędów, testach akceptacji użytkownika (UAT) i ciągłych integracja i automatyzacja testów.
Po przeczytaniu tego przewodnika lepiej zrozumiesz, jak wykorzystywać zwinne testowanie jako część cyklu życia oprogramowania!
Jeśli jesteś zwinnym programistą, testerem lub menedżerem produktu i szukasz lepszego sposobu dostarczania swoich produktów, w tym artykule wyjaśniono poszczególne etapy wraz z niezbędnymi działaniami, które należy podjąć.
Spis treści:
Przegląd cyklu życia testów zwinnych
Nie jest tajemnicą, że testowanie jest niezwykle ważne w świecie zwinnego programowania. Mimo to jest to często niedoceniana czynność w ramach zwinnego dostarczania. Powodem są oczywiście pieniądze w stosunku do czasu dostarczenia produkcji.
Ale bez szczegółowych testów nie byłoby gwarancji jakości ani niezawodności żadnego produktu opracowanego przez Twój zespół. Dlatego tak ważne jest zrozumienie cyklu życia testów zwinnych — od identyfikacji elementów roboczych po zrozumienie, jakiego rodzaju testy należy stosować w każdej fazie.
Zwinny cykl testowania wymaga zaangażowania programistów i testerów w każdy sprint. Dobre wykonanie pozwala na automatyzację testów na każdym etapie, co pomaga wykrywać błędy wcześniej i częściej, skracając czas późniejszego rozwiązywania problemów.
Zwinne testowanie pomaga również we wczesnej walidacji wymagań, a jako efekt uboczny poprawia zadowolenie klienta poprzez dostarczanie produktu wysokiej jakości.
Czym jest testowanie zwinne i jakie są jego zalety
Agile Testing to innowacyjna metodologia testowania oprogramowania, która wykorzystuje automatyzację do tworzenia iteracyjnego procesu testowania. To skoncentrowane na automatyzacji podejście pomaga zespołom szybko analizować wszelkie niespójności lub problemy w kodzie, a następnie testować modyfikacje w oparciu o te opinie.
Główne zalety tego procesu wydają się więc oczywiste:
- upewnić się, że testowanie ma niezbędny wpływ,
- prowadzi to do wydajniejszych czasów rozwoju,
- opracowany system ma ogólnie szybsze tempo rozwiązywania błędów,
- a satysfakcja klientów jest lepsza.
Jakość i szybkość są tutaj kluczowymi czynnikami, ponieważ sprint definiuje się jako krótki okres czasu (zwykle 2 do 4 tygodni). Im bardziej zespół może polegać na jakości zawartej w testach sprintu, tym większą pewność i szybszy postęp w rozwoju może osiągnąć zespół.
Skupienie się na automatyzacji powinno być głównym celem każdego zwinnego zespołu. Pozwala to zespołom zmniejszyć ryzyko kosztownych awarii i pozwala poświęcić więcej czasu na tworzenie nowych treści zamiast naprawiania tego, co już jest w fazie produkcji.
Kolejną korzyścią uboczną jest lepsze oszacowanie kosztów i harmonogramu projektu. Ponieważ produkt jest znacznie bardziej dojrzały i przewidywalny, jest mniej sytuacji, w których zespół musi poradzić sobie z nieoczekiwanymi problemami podniesionymi w trakcie sprintu bez wcześniejszego obliczenia takich komplikacji.
Etapy cyklu życia testowania zwinnego
Cykl życia testów zwinnych składa się z czterech odrębnych etapów.
Testy jednostkowe
Są to testy wykonywane przez programistów, gdy kod jest gotowy z programistycznego punktu widzenia. Jest wykonywany w izolacji w środowisku programistycznym, bez angażowania innych części systemu.
Testy jednostkowe są przeprowadzane w celu przetestowania kodu i mogą być wykonywane ręcznie lub automatycznie.
Jeśli jest wykonywany ręcznie, programista uruchamia swoje przypadki testowe względem kodu. Można to szybko rozgryźć, ale ze sprintu poświęconego na rozwój zajmuje więcej czasu, zwłaszcza w perspektywie długoterminowej.
Alternatywą dla tego jest utworzenie zautomatyzowanego kodu testu jednostkowego, który w zasadzie zweryfikuje kod funkcji po prostu go wykonując. Oznacza to, że programista musi poświęcić czas nie tylko na opracowanie nowej funkcji, ale także na opracowanie kodu testu jednostkowego, który przetestuje tę funkcję.
I chociaż może to wyglądać na większy wysiłek z perspektywy krótkoterminowej, jest to oszczędność czasu dla całego projektu, ponieważ takie testy jednostkowe są łatwe do ponownego wykorzystania również na późniejszych etapach testów sprintu. Można je nawet uwzględnić w zwykłych przypadkach testowych regresji, co pozwala zaoszczędzić jeszcze więcej czasu.
Wreszcie, im większe pokrycie kodu przez zautomatyzowane testy jednostkowe, tym lepsze metryki niezawodności kodu można zaprezentować klientowi.
Testy funkcjonalne
Testy funkcjonalne mają na celu określenie, jak dobrze działa funkcja aplikacji. Ten rodzaj testów służy zapewnieniu poprawnej funkcjonalności kodu, a nie aspektom technicznym (które były głównie częścią testów jednostkowych), a także ocenie, czy spełnia on potrzeby i oczekiwania użytkowników.
Innymi słowy, testy funkcjonalne służą do sprawdzenia, czy to, co zostało opracowane, spełnia wymagania stawiane przez użytkowników biznesowych.
Dobrą praktyką jest zebranie ważnych przypadków testowych z wyprzedzeniem i od odpowiednich interesariuszy (albo od właściciela produktu, albo nawet od użytkowników końcowych) i sporządzenie listy wszystkich takich przypadków testowych potrzebnych do treści w sprincie.
Automatyzacja testów funkcjonalnych wiąże się z większym wysiłkiem po stronie tworzenia testów, ponieważ są to złożone procesy, które należy zweryfikować, obejmując razem różne części systemu. Najlepszą strategią w tym przypadku jest powołanie dedykowanego zespołu wyłącznie do opracowywania testów funkcjonalnych zgodnie z linią, w której główny zespół programistów opracowuje nowe funkcje.
Jasne, dla projektu oznacza to zwiększone koszty utrzymania oddzielnego zespołu, ale ma też ogromny potencjał do zaoszczędzenia pieniędzy projektu w dłuższej perspektywie. Tylko menedżerowie projektu muszą wyjaśnić i konkretnie obliczyć korzyści i oszczędności, aby przedstawić użytkownikom biznesowym solidny argument, który doprowadzi do takiego wzrostu akceptacji kosztów projektu.
Z drugiej strony, jeśli czynność ta jest wykonywana ręcznie, może ją wykonać bardzo mały zespół (w niektórych przypadkach nawet jedna osoba). Wymagana będzie jednak ciągła ręczna i powtarzalna czynność w każdym sprincie. Z biegiem czasu, gdy zestaw funkcji systemu się rozszerza, nadrobienie solidnych testów funkcjonalnych sprint po sprincie może być trudniejsze.
Testy regresji
Celem testu regresji jest upewnienie się, że wszystko, co działało do tej pory, będzie działać również w następnej wersji. Należy przeprowadzić testy regresji, aby upewnić się, że nie występują problemy ze zgodnością między różnymi modułami.
Przypadki testowe do testów regresji są najlepsze, jeśli są regularnie konserwowane i przeglądane przed każdym wydaniem. W oparciu o konkretną specyfikę projektu najlepiej jest, aby były one proste, ale obejmowały większość bardzo podstawowych funkcjonalności i ważnych przepływów typu end-to-end przebiegających przez cały system.
Zwykle każdy system ma takie procesy, które dotykają wielu różnych obszarów i są to najlepsi kandydaci do przypadków testowych regresji.
Jeśli istnieją zautomatyzowane testy jednostkowe i testy funkcjonalne, stworzenie automatyzacji w testach regresji jest bardzo łatwym zadaniem. Po prostu użyj ponownie tego, co już masz, dla najważniejszej części systemu (np. dla procesów najczęściej używanych w produkcji).
Testy akceptacji użytkownika (UAT)
Wreszcie, UAT sprawdza, czy aplikacja spełnia wymagania niezbędne do wdrożenia produkcyjnego. Takie podejście sprawdza się najlepiej w przypadku częstego testowania oprogramowania w krótkich i intensywnych cyklach.
Testy UAT będą przeprowadzane wyłącznie przez osoby spoza zespołu zwinnego, najlepiej przez użytkowników biznesowych w dedykowanym środowisku, jak najbardziej zbliżonym do przyszłej produkcji. Alternatywnie właściciel produktu może zastąpić użytkowników końcowych.
W każdym razie powinien to być czysty, funkcjonalny test z perspektywy użytkownika końcowego, bez żadnego połączenia z zespołem programistów. Wyniki tych testów są tutaj, aby podjąć niezwykle ważną decyzję „go / no go” do wydania produkcyjnego.
Planowanie skutecznej strategii testów
Planowanie jest ważną częścią testowania zwinnego, ponieważ wiąże całą strategię. Musi również określić jasne oczekiwania dotyczące harmonogramu w kontekście sprintów.
Skutecznie zarządzając planowaniem testów zwinnych, zespoły mogą wytyczyć jasny kierunek, który prowadzi do efektywnego wykorzystania zasobów w ramach sprintu. Oczywiście oczekuje się ściślejszej współpracy między testerami a programistami.
Należy również opracować kompleksowy plan, aby określić, kiedy w każdym sprincie programistycznym mają miejsce testy jednostkowe, testy funkcjonalne lub testy akceptacyjne użytkownika. Dlatego każdy dokładnie wie, kiedy jego udział jest wymagany do udanego uruchomienia zwinnego.
Sposób ustawienia planu może być przedmiotem dalszych dyskusji i uzgodnień. Najważniejsze jednak, aby uczynić z tego proces i trzymać się go. Stwórz okresowość, która będzie niezawodna i przewidywalna.
Nie oddalaj się od procesu. W przeciwnym razie rzeczywistość będzie wręcz odwrotna – chaos i nieprzewidywalne wydania do produkcji.
Wykonywanie testów w oparciu o zbieranie wymagań
Testy muszą być przeprowadzone zgodnie z wymaganiami każdego etapu. Zgłoszenia są następnie otwierane po znalezieniu błędu lub problemu i przydzielane zespołowi programistów, który następnie będzie mógł dowiedzieć się, co należy naprawić lub zmienić w kodzie. Gdy wszystkie błędy zostaną naprawione, zwinne wykonywanie testów może być kontynuowane, dopóki wszystkie testy nie zakończą się pomyślnie.
Przeglądanie wyników i śledzenie błędów
Skuteczny przegląd wyników i solidny proces śledzenia błędów są niezbędne. Proces powinien obejmować wszystkich odpowiednich interesariuszy, od kierowników projektów i testerów po programistów, a ostatecznie zespoły wsparcia, ale także klientów w celu zebrania opinii.
Powinno to być na tyle kompleksowe działanie, aby problemy można było szybko zidentyfikować i zaradzić, zanim już zaplanowana data premiery będzie zagrożona.
Wybór narzędzia ponownie należy do zespołu. Ale raz wybrane działanie testowe musi obejmować niezawodne procesy śledzenia błędów w celu monitorowania problemów, ustalania ich priorytetów zgodnie z zależnościami, raportowania aktualizacji stanu od programistów w sprawie rozwiązania lub przeniesienia do dalszego zbadania, a następnie zamykania zgłoszeń po rozwiązaniu.
Przeglądanie pomaga zwinnym testerom zrozumieć zachowanie ich systemu, identyfikując błędy na każdym etapie, a nie później. Regularne przeglądy pozwalają również zwinnym zespołom identyfikować trendy i obszary wymagające poprawy, co pozwala im na ciągłą aktualizację ram testowania i szybsze tworzenie produktów lepszej jakości.
Finalizowanie wydania produktu za pomocą produkcyjnego testu dymu
Aby zmaksymalizować sukces wydania, jednym ze sposobów na zdobycie większej pewności jest test dymu z produkcją (tuż po wydaniu).
Ten test składa się z zestawu działań tylko do odczytu wewnątrz systemu produkcyjnego, które nie stworzą żadnych nowych losowych danych, ale nadal zweryfikują podstawową funkcjonalność systemu z punktu widzenia użytkowników końcowych.
Zaangażowanie odpowiednich interesariuszy w proces pomaga zapewnić spójność i rozliczalność, jednocześnie zwiększając pewność, że cele zostały osiągnięte. Ostatecznie testy te gwarantują pomyślne wydanie.
Ciągła integracja i automatyzacja testów w celu poprawy wydajności
Firmy coraz częściej wdrażają ciągłą integrację i automatyzację testów, aby przenieść zwinne procesy na wyższy poziom.
Jeśli zespół może wdrożyć automatyzację w kilku etapach, jak opisano powyżej, można je połączyć i połączyć w dedykowany potok testowy, który jest w zasadzie w pełni zautomatyzowanym procesem wsadowym wykonującym większość czynności testowych niezależnie i bez udziału jakiegokolwiek innego zespołu członek.
Z biegiem czasu tak kompleksowy proces testowania skróci łączny czas potrzebny na wszystkie fazy testowania. Ostatecznie może to doprowadzić do naprawdę szybkiego przyrostowego wydania produkcyjnego po zakończeniu każdego sprintu. Chociaż jest to idealny scenariusz przypadku, w rzeczywistości jest to trudne do osiągnięcia przy wszystkich etapach testowania. Jedynym sposobem, aby się tam dostać, jest automatyzacja.
Różnica między testowaniem zwinnym a testowaniem kaskadowym
Strategie testowania zwinnego różnią się od tradycyjnych strategii testowania kaskadowego na kilka sposobów, takich jak okresowość, równoległość lub czas poświęcony na każdą czynność.
Ale najbardziej zauważalną różnicą jest to, na czym skupia się każde podejście:
- Testowanie zwinne koncentruje się na ciągłych, szybkich iteracjach rozwoju i pętli sprzężenia zwrotnego w celu zidentyfikowania problemów i szybkiego udoskonalenia produktu. Iteracyjny proces skoncentrowany na współpracy z klientem, ciągłej integracji i planowaniu adaptacyjnym.
- Z drugiej strony tradycyjne testy kaskadowe kładą nacisk na proces liniowy, w którym każdy etap jest rozwiązywany osobno iw kolejności sekwencyjnej, pozostawiając informację zwrotną o całym rozwiązaniu tylko na ostatnim etapie projektu i bardzo blisko ostatecznej daty wydania produkcyjnego.
Oczywiście im szybciej problemy zostaną zidentyfikowane przez głównych interesariuszy, tym lepsza sytuacja dla projektu. Pod tym względem metodyka zwinna ma zdecydowanie większe szanse powodzenia.
Wniosek
Chociaż cykl życia testów zwinnych może wydawać się krótszy niż wodospad, w rzeczywistości tak nie jest. Cały proces jest ciągły i trwa do daty premiery produktu. W zależności od budżetu i czasu dostępnego dla każdego sprintu, będziesz musiał ustalić priorytety, które testy są wykonywane podczas tego konkretnego sprintu.
Dobrze zaplanowana strategia testów pomaga wybrać, które funkcje lub moduły wymagają więcej uwagi niż inne. Automatyzacja umożliwi włączenie kilku etapów testowania do tego samego sprintu, zwiększając ogólną niezawodność systemu od sprintu do sprintu.
Możesz teraz przyjrzeć się niektórym najlepszym praktykom w testowaniu scrum.