Jak dopasować testowanie do sprintu Scrum i jak pisać historie użytkowników w Scrum

15

Jestem kierownikiem zespołu programistów nowego projektu w mojej firmie. To pierwszy projekt, w którym firma wykorzysta Scrum. Mamy wodospad / iteracyjny SDLC. Licencjaci piszą dokumenty wymagań, przekazują je programistom i testują, deweloperzy zaczynają opracowywać i udostępnią testy w iteracjach. Testerzy długo testują wydanie, dzięki któremu deweloperzy kontynuują rozwój, ale także poprawki błędów dla bieżącej wersji. mam parę pytań

  1. W sprincie z powiedzmy 5 historii, kiedy wypuszczacie na testy? Czy jest to, jak tylko historia zostanie ukończona przez autora lub po zakończeniu wszystkich historii, ale przed końcem sprintu daje testowi wymagany czas na przetestowanie.
  2. Jeśli BA napisze historie użytkowników, jakie powinny być szczegóły. Tradycyjnie napisanie specyfikacji zawierającej cały układ interfejsu użytkownika, zachowanie, tekst itp. Zajmuje dużo czasu. Wydaje mi się, że moje pytanie dotyczy pisania historii, które można wdrożyć i przetestować.
  3. Nasz zespół testowy jest nietechniczny. Jak ważne jest automatyczne testowanie interfejsu użytkownika dla Scrum. Interfejs użytkownika oparty jest na WPF.

Mam duże doświadczenie w programowaniu przy użyciu zwinnych metod (TDD, recenzje kodu, refaktoryzacja itp.), Ale jako nowy w scrum.

edytuj: Przez iteracje mam na myśli, że jeśli jest 100 wymagań, możemy przejść do testowania, kiedy skończymy 30, 35, 35 wymagań, zamiast czekać na spełnienie wszystkich 100 wymagań.

softveda
źródło
4
We have a waterfall/iterative SDLC.Pracuj nad tym. Wodospad jest z definicji procesem sekwencyjnym, a nie iteracyjnym. Chociaż istnieją zmodyfikowane wodospady (takie jak model sashimi lub wodospad z podprojektami), wszystkie są sekwencyjne. Czy starasz się przejść do procesów iteracyjnych od bieżącego procesu sekwencyjnego?
Thomas Owens
1
@Pratik, jak Ci poszło? Czy udało Ci się lepiej współpracować z zespołem ds. Kontroli jakości?
flup

Odpowiedzi:

11

Jeśli testowanie jest odrębne od programowania, masz dwa osobne zespoły scrumowe. To zły pomysł, aby jedna ręka działała na drugą.

Twoi programiści muszą pisać własne testy, niezależne od tego innego zespołu. Musisz traktować ten inny zespół „testowy” jak swoich klientów.

W sprincie ... kiedy wypuszczasz na testy?

Po zakończeniu sprintu. Całkowicie zrobione. Oznacza to, że wykonałeś własne testy jednostkowe i jesteś pewien, że to działa. Po zakończeniu pracy zespołu programistycznego przekazujesz go innym zespołom w celu „testowania” lub „wdrożenia” lub czegokolwiek innego, co dzieje się w organizacji.

Wydaje mi się, że moje pytanie dotyczy pisania historii, które można wdrożyć i przetestować.

To zależy od zespołu. BA jest częścią zespołu programistów. Musisz pracować nad tym jako zespół (licencjat plus programiści), aby uzyskać odpowiednią ilość szczegółów. Wysiłek zespołu polega na uzyskaniu właściwych informacji od BA dla reszty zespołu.

Jak ważne jest automatyczne testowanie interfejsu użytkownika dla Scrum.

Kluczowy. Całkowicie wymagany do opracowania dowolnego interfejsu użytkownika. Programiści muszą wykonać wszystkie testy samodzielnie, zanim zostaną przekazane „zespołowi testowemu”. Jeśli istnieje interfejs użytkownika, muszą go przetestować. Jeśli nie ma interfejsu użytkownika, automatyczne testowanie interfejsu użytkownika nie jest wymagane. Testowanie jest wymagane i interfejs użytkownika musi zostać przetestowany. Zautomatyzowane testowanie jest obecnie najlepszą praktyką.


Dolna linia. Osobny zespół „testowy” i licencjat, który pisze każdy najmniejszy szczegół, nie jest optymalną organizacją dla Scrum. Scrum oznacza, że ​​musisz przemyśleć swoją organizację i procesy.

S.Lott
źródło
6
After you're development team is done, you release it to other teams for "testing" or "deployment" or whatever else happens in the organization. Czym różni się to od Iterative Waterfall? W tym przypadku sprint to naprawdę krótka Iteracja Wodospadu. Ten rodzaj pokonuje jedną z największych zalet Agile i Scrum IMO, że wszyscy BA, programiści i QA są razem w tym samym zespole i wszyscy wspólnie mają sprint, który wypuszczają. Przełamuje bariery występujące w projektach.
wałek klonowy
4
Czy możesz wyjaśnić, dlaczego automatyczne testowanie interfejsu użytkownika jest niezbędne? Scrum to struktura zarządzania projektami, która nie narzuca żadnych praktyk technicznych. Jedyne odniesienia do testów, które mogę znaleźć w odniesieniu do Scruma, to że Scrum Team jest zespołem wielofunkcyjnym. Chociaż wolałbym automatyczne testowanie, Scrum nie wymaga żadnych testów automatycznych ani żadnych testów, chociaż zaliczenie testów powinno być częścią Definicji Gotowości. Mówi tylko, że wszelkie przeprowadzone testy są wykonywane przez zespół. Twój wynik jest słuszny - obecna struktura organizacyjna nie jest dobrze dopasowana do Scruma.
Thomas Owens
2
Pytanie brzmi, skopiowane bezpośrednio z oryginalnego postu, podkreślono: „Jak ważne jest automatyczne testowanie interfejsu użytkownika dla Scruma ”. Dla Scruma to wcale nie jest ważne.
Thomas Owens
2
Sformułowanie w odpowiedzi brzmi, jakby automatyczne testowanie interfejsu użytkownika było częścią procesu Scrum, a nie jest. Ale to nie znaczy, że to nie jest dobra rzecz, którą zespół programistów powinien zrobić, aby poprawić jakość. Zgadzam się, że jest to słabo sformułowane pytanie, ale należy wprowadzić rozróżnienie między „czy jest to wymagane w przypadku Scruma” i „czy ukończenie automatycznego testowania interfejsu użytkownika powinno być częścią mojej definicji„ fabuły ”. Ostatecznie odpowiedź się nie zmienia, ale staje się bardziej zrozumiała, dlaczego jest wymagana.
Thomas Owens
9
Essential. Completely required.musi zostać zmieniony, aby odzwierciedlić, że nie jest to „niezbędne” lub „całkowicie wymagane” w ramach procesu Scrum. W tej chwili niedoinformowany czytelnik przeczytałby tę odpowiedź i wyciągnął wniosek, że jeśli nie przeprowadzasz automatycznych testów interfejsu użytkownika, nie wykonujesz Scruma. To fałszywy wniosek, ale całkowicie zrozumiały, biorąc pod uwagę treść tej odpowiedzi. Istnieje wyraźne rozróżnienie między „czymś, co powinieneś zrobić”, a „czymś nakazanym”.
Thomas Owens
9

Większość odpowiedzi, które zamierzam udzielić, dotyczy zwinnej metody tworzenia oprogramowania w porównaniu z metodą iteracyjnego wodospadu. Scrum jest po prostu popularną implementacją Agile.

  1. W typowym Scrumie nie ma oddzielnej fazy testowania, ponieważ testy formalne powinny odbywać się przez cały sprint. Gdy programista kończy historyjkę użytkownika, zasób kontroli jakości powinien już przygotować swoje przypadki testowe i rozpocząć testy w tym momencie. Jeśli ich testy wypadną pozytywnie, akceptują historię użytkownika i przechodzą do następnej. Gdy wszystkie historie użytkowników zostaną ukończone i zaakceptowane, sprint się skończy i zaczniesz następny. Wszystko to oczywiście zależy od ciągłej integracji, więc zmiany programistyczne są natychmiast dostępne dla QA. Dalszy rozwój powinien być zgodny z wytycznymi TDD, aby zapewnić, że testy regresji są tak szybkie i bezbolesne, jak to możliwe.

  2. BA jest dobrym pomysłem na pisanie historii użytkowników, ale dla bardziej szczegółowej i szczegółowej kontroli Historie użytkowników mogą towarzyszyć formalnym dokumentom wymagań. Historia użytkownika powinna być napisana z perspektywy pojedynczego użytkownika według roli. Wyraża potrzebę z punktu widzenia użytkownika, więc całkiem naturalnie, jeśli oprogramowanie zaspokoi obecnie wszystkie aspekty tej potrzeby, historia użytkownika zostanie zaspokojona. Historie użytkownika mogą składać się z historii użytkownika i zadań, które można przypisać. Zadania mogą nakładać się na wiele historii użytkowników.

  3. Zautomatyzowane testowanie interfejsu użytkownika może być dobrą rzeczą, ale osobiście uważam, że większy wysiłek w zakresie metod TDD i 100% pokrycia testów jednostkowych całej logiki biznesowej jest ważniejszy. Wydaje się, że większość zespołów programistów nie osiąga 100% zasięgu Business Logic, więc moim zdaniem zautomatyzowane testy interfejsu użytkownika byłyby stratą cennego czasu, który można by wykorzystać na napisanie większej liczby testów jednostkowych dla BL. To luksus, który moim zdaniem nie jest potrzebą.

wałek klonowy
źródło
Prawdziwe pytanie dotyczące 1: jeśli QA przetestuje każdą Historię użytkownika zaraz po jej zakończeniu, to przejdzie do następnej, w jaki sposób sprawdzisz, czy druga historia w tym samym sprincie nie złamała (być może w subtelny sposób) jednego z Historie użytkowników, które zostały już przetestowane? Rodzaj „regresji w ramach tego samego sprintu”. Mówię o ręcznej kontroli jakości, a nie o automatycznych zestawach testowych.
Andres F.,
@AndresF. Jeśli przestrzeganie procedury TDD wraz z CI, to jeśli rejestracja zepsuje istniejącą funkcjonalność, testy jednostkowe zakończą się niepowodzeniem i ludzie zostaną powiadomieni. Oczywiście jest to skuteczne tylko wtedy, gdy istnieje 100% testowanie logiki biznesowej, jednak proste problemy logiczne, środowiskowe lub integracyjne oraz logika prezentacji mogą potencjalnie mieć defekty w rozwoju nowych historii użytkowników, które nie zostaną wykryte. Zautomatyzowane testy interfejsu użytkownika, zgodnie z sugestią S.Lott, przechodzą długą drogę, aby złapać większość z nich, ale ostatecznie niewiele więcej niż szybki test dymu powinien wykryć te problemy. cd ...
wałek klonowy
... cd. Jeśli zauważysz, że jest to powtarzający się problem, możesz mieć głębsze wady projektowe lub problemy, które należy rozwiązać, takie jak ścisłe połączenie i niska spójność, które powodują, że kod jest wyjątkowo kruchy.
wałek klonowy
@maple_shaft: Łatwo to powiedzieć, ale QA nie lubi wydania w trakcie testów. Często też meldujemy się w kompilacji CI, ale wydanie odbywa się tylko na żądanie. Obecny zespół testowy nie jest w stanie napisać automatycznego testu interfejsu użytkownika. Wykonują wyłącznie ręczne testy. Trudno byłoby mi to zmienić.
softveda
@Pratik Rozumiem, jak trudno mi uwierzyć. Znam ból. Być może możesz przedłużyć sprint, ale masz trzy lub cztery wersje środowiska testowego na sprint? W ten sposób zespół testujący może wyjść na cały dzień w środku przypadku testowego i mieć pewność, że środowisko nie zostało zmienione z dnia na dzień.
wałek klonowy
4
  1. W Scrumie powinieneś wygenerować potencjalnie wysyłany przyrost oprogramowania na końcu każdego sprintu. W rezultacie Scrum promuje koncepcję całego zespołu lub zespołu wielofunkcyjnego, w którym każda umiejętność wymagana do prowadzenia danej historii użytkownika musi być obecna w zespole.

    W moim obecnym projekcie, ponieważ w pełni przetestowana historia jest częścią naszej definicji ukończenia, wbudowaliśmy testerów w zespoły. Podczas pierwszych dni sprintu, podczas gdy programiści rozpoczynają pracę nad historiami pierwszych użytkowników, testerzy przygotują scenariusze testowe i skonfigurują niektóre dane testowe. Gdy tylko twórca jednej z historii użytkowników zostanie ukończony, przetestują ją.

  2. Jest to jedna z największych trudności w Scrum IMO. Musisz znaleźć odpowiednią ilość specyfikacji niezbędnych do uzyskania możliwej do wdrożenia, testowalnej historii użytkownika. Zbyt wiele wstępnych analiz, dokumentacji i specyfikacji spowoduje sztywny plan, który nieuchronnie okaże się błędny w trakcie sprintu. I odwrotnie, historia użytkownika, która nie została jasno zdefiniowana i wyrażona przez właściciela produktu, doprowadzi do nasyconego pasma komunikacyjnego między programistami a PO podczas Sprintu i opóźnień w rozwoju, podczas gdy PO podejmuje decyzje dotyczące historii użytkowników w połowie sprintu .

    W naszym przypadku zdefiniowaliśmy odpowiednią ilość szczegółów, aby historia użytkownika była 1 / opisem w formie „jako… chcę… aby…” i 2 / serii akceptacji kryteria Rzadko przygotowujemy makiety interfejsu użytkownika, może się to zdarzyć podczas planowania sprintu, ale są to kolejne szkice, które są następnie odrzucane.

  3. Z mojego doświadczenia wynika, że ​​automatyczne testowanie interfejsu użytkownika jest niezwykle czasochłonne i wyjątkowo kruche. Istnieją sposoby, aby to zrobić w WPF, ale przed przejściem w ten sposób ostrożnie zastanowiłbym się nad kosztami utrzymania takich testów z korzyściami.

guillaume31
źródło
2

Praca w coraz krótszych iteracjach powoduje, że wszystkie te przekazy stają się coraz droższe. Możesz zmniejszyć te koszty, stosując głupią, prostą zasadę: zmniejsz rozmiary partii o połowę, zmień sposób pracy, aby było to wygodne, powtarzaj, aż będziesz szczęśliwy.

Weź przykład z 5-piętrowego sprintu. Jeśli twoje zespoły są przyzwyczajone do pisania kodu dla wszystkich 5 opowieści, a następnie testowania wszystkich 5 opowiadań, wówczas wielkość partii wynosi 5 opowiadań. Przetnij to na pół. W następnym sprincie najpierw pracuj nad 3 najpilniejszymi historiami, przygotowując je do testowania tak szybko, jak to możliwe. Gdy testerzy testują te 3 historie, reszta może przygotować pozostałe 2 historie do testowania. Spowoduje to pewne narastające bóle. Zmień sposób pracy, aby było to wygodniejsze.

Na przykład więcej osób będzie pracować nad każdą historią razem, więc spróbuj sparować więcej i sprawdź, czy to pomoże ci pracować bardziej stabilnie. A może testerzy znajdą problemy w historii 2, które odwracają uwagę niektórych programistów podczas próby pracy nad historią 5, więc zachęcaj programistów i testerów do następnego sprintu, aby przedyskutowali wcześniej, jak przetestować jedną z historii w „pierwszej partii” ”, aby programiści nie popełnili błędu, który tester może łatwo złapać za pomocą testu.

Może zająć kilka sprintów, aby rozwiązać wielkie problemy związane z testerami testującymi małą partię historii, podczas gdy programiści pracują nad kolejną partią historii. Gdy stanie się wygodny, ponownie zmniejsz wielkość partii o połowę. I ponownie. W ciągu około roku zespół będzie wygodnie testował historie, ponieważ programiści uważają, że z nimi skończyli i prawdopodobnie popełniają mniej błędów po drodze. Każda historia zostanie ukończona wcześniej.

Oczywiście w tym momencie możesz teraz robić to samo z partiami otrzymywanymi przez zespół od właścicieli produktów lub wysyłanymi przez zespół do organizacji operacyjnej. I tak dalej. W tym momencie możesz poradzić sobie z tym „ile szczegółów powinni napisać licencjaci dla opowiadań?” problem.

Nawiasem mówiąc: aby testerzy mogli skrócić czas realizacji, będą musieli wprowadzić pewną automatyzację, poprzez kombinację uczenia się automatyzacji i programistów pomagających im w automatyzacji. Podczas próby zmniejszenia wielkości partii dowiesz się, kiedy trzeba rozwiązać te problemy. Nie dodawaj automatyzacji tylko dlatego, że książka mówi, że jej potrzebujesz.

Mam nadzieję, że ci to pomoże.

JB Rainsberger
źródło
0

Po prostu chcę podzielić się niektórymi doświadczeniami, jak poniżej, i mam nadzieję, że Ci się przyda.

W sprincie z powiedzmy 5 historii, kiedy wypuszczacie na testy? Czy jest to, jak tylko historia zostanie ukończona przez autora lub po zakończeniu wszystkich historii, ale przed końcem sprintu daje testowi wymagany czas na przetestowanie.

Dla każdej historii dużego użytkownika należy ją podzielić na wiele pod-zadań, a gdy zadania podrzędne zostaną całkowicie wykonane przez programistę, należy je natychmiast przekazać do kontroli jakości. Wada powinna zostać naprawiona po testach dla tych testów zadań podrzędnych.

Jeśli BA napisze historie użytkowników, jakie powinny być szczegóły. Tradycyjnie napisanie specyfikacji zawierającej cały układ interfejsu użytkownika, zachowanie, tekst itp. Zajmuje dużo czasu. Wydaje mi się, że moje pytanie dotyczy pisania historii, które można wdrożyć i przetestować.

W Scrumie historie użytkowników powinny być w dowolnym formacie, o ile mają miejsce rozmowy wokół nich, a nie oczekuje się, że zostaną zakończone lub statyczne. Mała historia, zwana po prostu historią użytkownika, jest dobrze zrozumiała i można ją wdrożyć w sprincie. Priorytet historii może opierać się na ROI, wartości biznesowej lub czymkolwiek innym, co użytkownik zgadza się, jest ważne. To są działania PO.

Nasz zespół testowy jest nietechniczny. Jak ważne jest automatyczne testowanie interfejsu użytkownika dla Scrum. Interfejs użytkownika oparty jest na WPF

Zastosowanie testów automatyzacji w Scrumie jest dość trudnym działaniem. Ponieważ wszystkie funkcje są zaimplementowane niekompletnie i niezbyt stabilne, aby umożliwić QC wdrożenie przypadku testowego za pomocą jakiegoś narzędzia do automatycznego testowania. Należy to zrobić dla sprintu o nazwie: regresja.

Danh
źródło