is there any start stop boundary qa s role scrum
Jaka jest rola kontroli jakości w Scrumie: działania Scrum dla testerów
Ten artykuł to nie tylko samouczek dotyczący niektórych procesów lub metod, ani instrukcje dotyczące pracy jako osoba zapewniająca jakość. Jest to raczej artykuł, w którym chcę podzielić się własnym doświadczeniem z pracy na stanowisku Senior QA w SCRUM.
Mój poprzedni CTO zawsze to mówił „Wraz z wolnością przychodzi odpowiedzialność”. Jeśli masz swobodę wykonywania swojej pracy na swój sposób, to ty i tylko ty jesteś odpowiedzialny za swoją pracę, zadania lub czynności.
O to właśnie chodzi w Scrumie !! Pozwólcie, że przedstawię wam podstawowe pojęcie o Scrumie, gdy będziemy kontynuować.
Czego się nauczysz:
Przegląd Scruma
Scrum jest podzbiorem zwinna metodologia i jest lekką strukturą procesu, która jest szeroko stosowana.
Scrum pomaga nam zadbać o zadowolenie klientów, dając im produkt w małych modułach, jednocześnie uświadamia klientowi, że jego często zmieniające się wymagania mogą spowalniać działania. Wersje są krótkie, a praca wykonywana jest zgodnie z możliwościami zaangażowanego zespołu, stąd szanse na awarie lub niezadowolenie klientów są znacznie zmniejszone.
Z drugiej strony wymagania (w tym przypadku User Stories) są finalizowane przed rozpoczęciem Sprintu, aby uniknąć przeróbek, co skutkuje opóźnionym lub nieudanym Sprintem (wyjątki są zawsze).
Jednak największym wyzwaniem dla kontroli jakości jest to, że okres wydawania jest krótki, a Sprint to w większości cykl 15-dniowy. Dlatego dostarczenie „wolnego” od błędów produktu w maksymalnie 4-5 dni (skracając czas na rozwój) wymaga dużo wysiłku i inteligentnego myślenia.
Jestem QA mojego zespołu:
O tak, jestem QA mojego zespołu i jestem ważnym graczem w moim zespole. Dlaczego?? Ponieważ klienci, licencjobiorcy, Scrum Master i wszyscy inni są niejasni co do jakości, wyglądu i działania oraz wydajności aplikacji lub produktu.
W Scrumie, ponieważ czas trwania sprintu jest krótki, QA musi działać w inteligentny sposób, a zatem potrzeba zaangażowania się od QA od samego początku „Planowanie” staje się bardzo ważna. Zdarza się, że QA może odgrywać rolę właściciela produktu proxy, gdy zamówienie zakupu jest niedostępne, pomagając w ten sposób BA w tworzeniu scenariuszy / przypadków testowych kryteriów akceptacji.
Deweloperzy podchodzą do kontroli jakości również wtedy, gdy mają problemy z funkcjonalnością lub regułami biznesowymi. W Scrumie nacisk kładziony jest tylko na sprawne i udane wydanie Sprintu i nie chodzi o „moją pracę” lub „Twoją pracę”, aby podać pomocną dłoń, gdy zespół zwraca się do Ciebie o pomoc.
W tworzeniu więzi w zespole Scrum, zdrowe relacje między członkami zespołu odgrywają bardzo istotną rolę, a będąc osobą zapewniającą jakość, powinieneś być bardzo ostrożny podczas komunikowania swojej opinii na temat historyjek użytkowników, które testujesz. Twoja komunikacja powinna dotyczyć historii użytkownika lub funkcjonalności, a nie osoby, która nad tym pracowała.
W Scrumie QA nie jest oceniana ani doceniana za liczbę wykrytych błędów, ale także za to, jak wchodzi w interakcje z zespołem, pomagając zespołowi i motywując go nawet w trudnych chwilach.
Oprócz testowania zadań sprintu, pisanie planów testów / przypadków testowych / dokumentów wydania również próbuje angażować więcej, ponieważ czas trwania sprintu jest krótki, a cel jest taki sam dla wszystkich „Aby skutecznie dostarczać działający, wolny od błędów produkt, pomagając sobie nawzajem”.
QA jest zaangażowana w prawie wszystkie czynności wykonywane w Sprincie i technicznie nie ma granic dla rozpoczęcia lub zakończenia działań QA. W przeciwieństwie do tradycyjnego modelu Waterfall, w którym kontrola jakości ogranicza się tylko do testowania wydania, tutaj kontrola jakości ma znacznie więcej obowiązków. Dlatego sugerowałbym wypróbowanie i wykonanie większej liczby poniższych czynności.
Działania do naśladowania
Poniżej przedstawiono kilka czynności, które sugerowałbym wykonywać jako QA w Scrumie.
jak otworzyć pliki .bin windows 10
# 1) Mieszkaj głębiej:
Rozumiem przez to, że kiedy historyjki użytkowników i ich kryteria akceptacji są gotowe, dokładnie je przestudiuj i zastanów się głębiej nad zależnościami, ukrytymi skutkami i czy istnieje lepszy sposób na zrobienie tego.
Komunikuj się i współpracuj z BA i zespołem programistów w tej sprawie, ponieważ może się zdarzyć, że oni również o tym nie pomyśleli. Podziel się swoimi pomysłami i spostrzeżeniami z zespołem.
Jeśli zauważysz, że istnieją ukryte przeszkody lub negatywne skutki, podniesienie ich za pomocą Scrum Mastera i programistów da im czas na przemyślenie i odpowiednie działanie. Ta aktywność w Scrumie staje się bardzo krytyczna, gdy projekt jest na dużą skalę i gdy w zespołach są moduły.
Teraz podczas studiowania zależności, wpływ jest bardzo ważny dla kontroli jakości, a nawet uświadamia o tym zespołowi programistów. Aby to zrobić, przedyskutuj z działami kontroli jakości innych zespołów i weź od nich uwagi.
# 2) Zaangażuj się w szacunki:
Zwykłą praktyką jest włączanie QA do oszacowań, ale często z powodu małego sprintu, QA może nie zostać poproszony o oszacowanie testowania zadań i pozostawienie ich 3/4/5 dni na testowanie.
Nigdy tego nie akceptuj. Podnieś głos, jeśli musisz, ale upewnij się, że podajesz szacunkową ocenę testu, która powinna obejmować czas potrzebny na każdą pracę.
Może obejmować czas na badania, czas na konfigurację, czas na gromadzenie danych historycznych itp., Ale należy być ścisłym i konkretnym co do czasu wymaganego do przeprowadzenia czynności testowych i dodać te wartości czasu do historii użytkownika wraz z czasem zadań programistycznych .
Jest to bardzo ważne, ponieważ jeśli spróbujesz wykonać swoją pracę w wyznaczonym czasie i nie będziesz w stanie jej wykonać, tylko Ty będziesz odpowiedzialny za niepowodzenie. Po dodaniu czasu zapewniania jakości Scrum Master, PO będzie świadomy czynności związanych z zapewnianiem jakości i wymaganego czasu.
# 3) Parowanie Dev QA:
Idealnie, w Scrumie, Historie użytkowników Sprintu są przekazywane do testów po zakończeniu programowania i po zakończeniu testów deweloperskich, ale problem polega na tym, że do czasu przekazania ich do kontroli jakości do testów zaledwie 4-5 dni do wersji demonstracyjnej lub recenzji.
Teraz, jeśli podczas kontroli jakości odkryjesz nawet 4 blokady lub awarie funkcjonalne, będziesz musiał pracować późną nocą lub w weekend, aby dotrzymać daty wydania, ponieważ będą do wykonania testy funkcjonalne, regresje itp. Wydaje się, że jest to tradycyjny model wodospadu, który nie jest najlepszym sposobem, w Scrumie jest to najmądrzejszy sposób „Lepiej zapobiegać defektom niż znajdować defekty”.
Dlatego rozwiązaniem jest wykonanie parowania Dev QA i wykonanie podstawowej rundy testów na konfiguracji deweloperskiej, gdy tylko deweloperzy będą gotowi z historiami, nawet przed formalnym wydaniem do testów.
Poniższe kryteria można wziąć pod uwagę, aby wykonać BVT w konfiguracji deweloperskiej dla historyjek użytkownika:
- Kryteria akceptacji dla każdego historyjki użytkownika: BVT historyjek użytkownika zgodnie z kryteriami akceptacji.
- Brak zaufania do programistów: Czasami programiści nie mają pewności co do niektórych implementacji i dlatego omawiają takie implementacje i robią BVT dla tych na tym samym ustawieniu dewelopera.
- Zależności / testy wpływu: BVT zależności lub wpływu na / z innych modułów nowych implementacji.
- Testów jednostkowych: Wykonaj BVT z twórcą testów jednostkowych, które utworzył, w razie potrzeby pomóż im, dodając lub aktualizując testy jednostkowe.
Pomoże to w zmniejszeniu liczby błędów tam i z powrotem, zaoszczędzi wszystkim czas, ponieważ przed udostępnieniem do kontroli jakości większość błędów powodujących awarie lub funkcjonalnych została już naprawiona. Pamiętaj, aby zarejestrować te usterki w swoich narzędziach przed przeglądem sprintu i przenieść je do stanu „zamkniętego”.
# 4) QA na białej tablicy:
Zawsze osobiście zachęcałem mój zespół do umieszczania zadań QA na tablicy White Scrum, w tym również błędów. Pomaga to Scrum Masterowi w ustaleniu statusu QA historii użytkownika, po prostu patrząc na tablicę.
Nie. błędów na liście zadań do wykonania, błędów na liście w toku, czynności QA na liście zadań do wykonania, w toku i zakończonych mówią same za siebie. Uważam, że to naprawdę bolesne, gdy ktoś przychodzi z pytaniem o stan testowania poszczególnych historii do Sprintu, ponieważ muszę poświęcić dodatkowy czas, aby wyciągnąć mój status z narzędzi, skompilować i pokazać je lub przygotować wiadomość e-mail.
Po prostu wolę skierować osobę do Tablicy Scrumowej i pozwolić jej zrobić to dla siebie. Preferuj jasny, wyjątkowy kolor pasków QA Sticky.
# 5) Dokumentacja:
Jest to jedna z wad lub wad Scruma, że ze względu na mały rozmiar Sprintu nie ma zbyt wiele czasu na dokumentację i nigdy nie widziałem w zespole Scruma autora technicznego. Scrum Master / BA może nie i nie zawsze aktualizuje dokumenty dotyczące informacji o produkcie.
Problem pojawia się, gdy dołączają nowi członkowie lub w najgorszym przypadku, gdy zmieniają się zasady biznesowe, funkcje i jak je śledzić, ponieważ wyszukiwanie informacji w historiach użytkowników „Gotowych” będzie jak szukanie igły w stogu siana.
Rozwiązaniem jest utworzenie oddzielnego zadania w sprincie, gdy tylko jest to możliwe (głównie w wolnych chwilach lub gdy obciążenie pracą jest bardzo mniejsze) dla dokumentacji, aby można było przejrzeć dokumenty i zaktualizować lub zmusić Scrum Mastera lub BA do ich aktualizacji.
QA to właściwa osoba do pomocy w aktualizowaniu dokumentów, ponieważ to Ty testujesz, weryfikujesz historyjki użytkownika i znasz funkcjonalność. Zrób to sam, jeśli nie ma BA i jeśli Twój Scrum Master jest zajęty aktualizowaniem.
# 6) Przegląd sprintu / Demo sprintu:
Przeważnie zdarza się, że osoba odpowiedzialna za kontrolę jakości jest wybierana do przekazania wersji demonstracyjnej PO i Interesariuszom. ale jeśli nie, przekonaj do tego swojego Scrum Mastera. Osoba odpowiedzialna za kontrolę jakości to właściwa osoba, która przeprowadzi demo, ponieważ testowała historię użytkownika.
QA może przeprowadzić demonstrację z biznesowego punktu widzenia, ponieważ zna funkcje, przepływy i reguły biznesowe. Przygotuj się dobrze do demonstracji i postaraj się odpowiedzieć na każde pytanie OP i interesariuszy. Pomoże Ci to stać się dla nich osobą kontaktową w przypadku braku Scrum Mastera i licencjata.
# 7) Zachowuj się jak licencjat:
Nie jest to zwykłe zadanie i nawet nie oczekuje się go od QA, ale spróbuj dostać się do tej roli, gdy pojawi się szansa, ponieważ QA jest najlepszą osobą na BA. Na przykład spróbuj pomyśleć i zwizualizować, czy przepływy, funkcje lub reguły biznesowe można zmodyfikować w sposób korzystny dla klienta.
Zastanów się i poszukaj aktualnych trendów w interfejsie użytkownika, wyglądu i stylu aplikacji oraz tego, jak można ją beatyfikować, uczynić bardziej przyjazną dla użytkownika itp. Jeśli zespół utknie w jakimś problemie, zaangażuj się i spróbuj podać prosty i inteligentny rozwiązanie. To wzmocni Twoją rolę i będzie czynnikiem przyczyniającym się do rozwoju Twojej kariery.
Szanse pojawiają się podczas rozmów z PO, gdy omawiane są pewne problemy lub w trakcie przeglądu / demonstracji, w którym możesz podać sugestie.
Wniosek
Scrum to zupełnie inna metodologia od zwykłej metody Waterfall, a Scrum Master jest pomocnikiem. Dlatego nie oczekuj, że będzie definiował Twoje działania za Ciebie.
W Scrumie nie ma początkowej ani końcowej granicy roli osoby zapewniającej jakość. QA potrzebuje i musi być zaangażowane w każde działanie od samego początku do końca, od planowania wstępnego do przeglądu / demonstracji sprintu i musi uczestniczyć we wszystkich działaniach.
Pomoże to zrozumieć produkt lub aplikację, ponieważ (jak powiedziałem wcześniej) nie ma odpowiedniej dokumentacji podczas pracy w Scrumie. Oczekuje się, że będziesz odpowiedzialny, zmotywowany i proaktywny. Dlatego nie czekaj, aż ktoś przyjdzie i powie Ci, co lub jak masz zrobić.
Powinieneś samodzielnie podejmować inicjatywy, pomagać zespołowi w każdy możliwy sposób, utrzymywać zdrowe relacje, śledzić bieżące sprawy w zespole i co najważniejsze mieć jasność co do zadań w danym sprincie.
Tutaj nie ma menedżerów, którzy będą Cię monitorować lub śledzić Twoje działania. Zawsze bądź gotowy, aby pomóc swojemu zespołowi, a wykorzystasz najlepsze możliwości.
Zapraszam do wyrażenia swoich przemyśleń / sugestii na temat tego artykułu informacyjnego w sekcji komentarzy poniżej.
rekomendowane lektury
- Rola analityków biznesowych w SCRUM i dlaczego kontrola jakości jest najlepsza dla tej roli?
- Agile Scrum Online Quiz: Sprawdź swoją wiedzę na temat Agile Scrum
- Instalowanie aplikacji na urządzeniu i rozpoczęcie testowania z Eclipse
- Kanban vs Scrum vs Agile: szczegółowe porównanie w celu znalezienia różnic
- Jak dostarczać wartościowe funkcje oprogramowania w krótkim okresie czasu przy użyciu zwinnego procesu Scrum
- Manifest Agile: Zrozumienie wartości i zasad Agile
- Triaging defektów w Scrumie: jak to jest zorganizowane w konfiguracji Scruma
- Najlepsze narzędzia do testowania oprogramowania 2021 [Narzędzia do automatyzacji testów QA]