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

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ń.

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.

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ą.

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.

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.

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.