Testowanie zwinne - Scrum

Zwolennicy Scruma Whole Team Approach, w tym sensie, że każdy członek zespołu musi brać udział w każdym działaniu projektowym. Zespół Scrumowy samoorganizuje się, odpowiadając za rezultaty projektu. Podejmowanie decyzji pozostawia się zespołowi, co skutkuje podjęciem odpowiednich działań w odpowiednim czasie bez opóźnień. Takie podejście zachęca również do właściwego wykorzystania talentu zespołu zamiast ograniczania się do jednej czynności. Testerzy uczestniczą również we wszystkich projektach i działaniach rozwojowych, wnosząc swój wkład w testowanie.

Cały zespół pracuje razem nad strategią testów, planowaniem testów, specyfikacją testów, wykonaniem testów, oceną testów i raportowaniem wyników testów.

Wspólne tworzenie historii użytkownika

Testerzy uczestniczą w tworzeniu historii użytkownika. Testerzy przekazują swoje pomysły na temat możliwego zachowania systemu. Pomaga to klientowi i / lub użytkownikowi końcowemu zrozumieć system w rzeczywistym środowisku, a tym samym uzyskać jasność co do tego, czego tak naprawdę chcą. Powoduje to szybsze zamrażanie wymagań, a także zmniejsza prawdopodobieństwo późniejszych zmian w wymaganiach.

Testerzy wymyślają również kryteria akceptacji dla każdego scenariusza uzgodnionego przez klienta.

Testerzy przyczyniają się do tworzenia testowalnych historyjek użytkownika.

Planowanie wydania

Planowanie wydania jest wykonywane dla całego projektu. Jednak struktura Scruma obejmuje iteracyjne podejmowanie decyzji, ponieważ więcej informacji jest uzyskiwanych w odpowiednim czasie wykonywania sprintów. Stąd sesja planowania wydania na początku projektu nie musi tworzyć szczegółowego planu wydania dla całego projektu. Może być aktualizowany na bieżąco, o ile dostępne są odpowiednie informacje.

Każdy koniec sprintu nie musi mieć uwolnienia. Wydanie może nastąpić po grupie sprintów. Głównym kryterium wydania jest dostarczenie klientowi wartości biznesowej. Zespół decyduje o długości sprintu, uwzględniając planowanie wydania jako dane wejściowe.

Planowanie wydania jest podstawą podejścia do testów i planu testów do wydania. Testerzy szacują nakłady testowe i planują testy do wydania. Gdy plany wydania ulegną zmianie, testerzy muszą poradzić sobie ze zmianami, uzyskać odpowiednią podstawę do testów, biorąc pod uwagę szerszy kontekst wydania. Testerzy wykonują również testy, które są wymagane na koniec wszystkich sprintów.

Planowanie sprintu

Planowanie sprintu odbywa się na początku każdego sprintu. Backlog sprintu jest tworzony z historyjek użytkowników pobranych z rejestru produktu w celu wdrożenia w tym konkretnym sprincie.

Testerzy powinni:

• Określ testowalność historyjek użytkownika wybranych do sprintu
• Twórz testy akceptacyjne
• Zdefiniuj poziomy testów
• Zidentyfikuj automatyzację testów

Testerzy aktualizują plan testów, uwzględniając szacunki nakładu pracy i czasu trwania testów w sprincie. Zapewnia to czas na wymagane testy podczas sprintów ograniczonych czasowo, a także odpowiedzialność za wysiłek testowy.

Analiza testów

Kiedy rozpoczyna się sprint, gdy programiści przeprowadzają analizę historii w celu projektowania i implementacji, testerzy przeprowadzają analizę testów dla historii w rejestrze sprintu. Tester tworzy wymagane przypadki testowe - zarówno testy manualne, jak i automatyczne.

Testowanie

Wszyscy członkowie zespołu Scrumowego powinni brać udział w testowaniu.

• Programiści wykonują testy jednostkowe podczas tworzenia kodu dla historyjek użytkownika. Testy jednostkowe są tworzone w każdym sprincie, przed napisaniem kodu. Przypadki testów jednostkowych pochodzą ze specyfikacji projektu niskiego poziomu.

• Testerzy wykonują funkcjonalne i niefunkcjonalne cechy historyjek użytkownika.

• Testerzy wspierają innych członków zespołu scrumowego swoim doświadczeniem w testowaniu, tak aby cały zespół był zbiorowo odpowiedzialny za jakość produktu.

• Na koniec sprintu klient i / lub użytkownicy końcowi przeprowadzają testy akceptacji użytkowników i przekazują informacje zwrotne zespołowi scrumowemu. Stanowi to wkład do następnego sprintu.

• Wyniki testów są gromadzone i przechowywane.

Testowanie automatyczne

Testowanie automatyzacyjne ma duże znaczenie w zespołach Scrumowych. Testerzy poświęcają czas na tworzenie, wykonywanie, monitorowanie i utrzymywanie zautomatyzowanych testów i wyników. Ponieważ zmiany mogą nastąpić w dowolnym momencie w projektach scrumowych, testerzy muszą dostosować się do testowania zmienionych funkcji, a także do testów regresyjnych. Testowanie automatyczne ułatwia zarządzanie wysiłkiem testowym związanym ze zmianami. Zautomatyzowane testy na wszystkich poziomach ułatwiają osiągnięcie ciągłej integracji. Testy automatyczne działają znacznie szybciej niż testy ręczne bez dodatkowego wysiłku.

Testowanie ręczne koncentruje się bardziej na testowaniu eksploracyjnym, podatności na uszkodzenia produktu i przewidywaniu defektów.

Automatyzacja czynności testowych

Automatyzacja czynności testowych zmniejsza obciążenie związane z powtarzalną pracą i skutkuje oszczędnością kosztów. Zautomatyzuj

• Generowanie danych testowych
• Ładowanie danych testowych
• Zbuduj wdrożenie w środowisku testowym
• Zarządzanie środowiskiem testowym
• Porównanie danych wyjściowych

Testowanie regresji

Podczas sprintu testerzy testują kod, który jest nowy / zmodyfikowany w tym sprincie. Jednak testerzy muszą również upewnić się, że kod opracowany i przetestowany we wcześniejszych sprintach również działa z nowym kodem. Dlatego w scrumie znaczenie ma testowanie regresji. Zautomatyzowane testy regresji są uruchamiane w ciągłej integracji.

Zarządzanie konfiguracją

W projektach Scruma używany jest system zarządzania konfiguracją, który wykorzystuje zautomatyzowane struktury kompilacji i testów. Pozwala to na wielokrotne uruchamianie analizy statycznej i testów jednostkowych, gdy nowy kod jest wprowadzany do systemu zarządzania konfiguracją. Zarządza również ciągłą integracją nowego kodu z systemem. Automatyczne testy regresji są uruchamiane podczas ciągłej integracji.

Przypadki testów ręcznych, testy automatyczne, dane testowe, plany testów, strategia testów i inne artefakty testowe muszą być kontrolowane pod kątem wersji i zapewnić odpowiednie uprawnienia dostępu. Można to osiągnąć, utrzymując artefakty testowania w systemie zarządzania konfiguracją.

Praktyki testowania zwinnego

Testerzy w Zespole Scrumowym mogą przestrzegać następujących Praktyk Agile -

• Pairing- Dwóch członków zespołu siedzi razem i współpracuje. Dwie osoby mogą być dwoma testerami lub jednym testerem i jednym programistą.

• Incremental Test Design - Przypadki testowe są opracowywane w miarę postępów Sprintów i sumowania Historii użytkowników.

Wskaźniki Agile

Podczas tworzenia oprogramowania, gromadzenie i analiza metryk pomaga w ulepszaniu procesu, a tym samym w osiąganiu lepszej produktywności, jakości wyników i satysfakcji klienta. W programowaniu opartym na Scrumie jest to możliwe i testerzy muszą zwracać uwagę na metryki, których potrzebują.

Do rozwoju Scruma sugerowanych jest kilka wskaźników. Istotne wskaźniki to -

• Ratio of Successful Sprints - (Number of successful Sprints / Total number of Sprints) * 100. Udany Sprint to taki, w którym Zespół mógłby wypełnić swoje zobowiązanie.

• Velocity- Szybkość drużyny jest oparta na liczbie punktów fabularnych, które drużyna zdobyła podczas sprintu. Punkty opowieści są miarą historii użytkowników zliczanych podczas szacowania.

• Focus Factor - (Velocity / Team’s Work Capacity) / 100. Współczynnik skupienia to procent wysiłku zespołu, który skutkuje ukończeniem historii.

• Estimation Accuracy - (Estimated effort / Actual effort) / 100. Dokładność oszacowania to zdolność zespołu do dokładnego oszacowania wysiłku.

• Sprint Burndown- Praca (w punktach fabularnych lub w godzinach), czyli Pozostałe vs. Praca, która powinna pozostać idealnie (zgodnie z oszacowaniem).

  • Jeśli jest więcej, oznacza to, że Zespół podjął więcej Pracy, niż jest w stanie wykonać.

  • Jeśli jest mniejszy, oznacza to, że Zespół nie oszacował dokładnie.

• Defect Count- Liczba usterek w Sprincie. Liczba defektów to liczba defektów w oprogramowaniu w stosunku do zaległości.

• Severity of Defects- Wady można podzielić na drobne, poważne i krytyczne według ich wagi. Testerzy mogą zdefiniować kategoryzację.

Retrospektywy sprintu

W retrospekcjach sprintu wezmą udział wszyscy członkowie zespołu. Dzielą się -

• Rzeczy, które poszły dobrze
• Metrics
• Zakres ulepszeń
• Działania do zastosowania