Proces testowy w SCRUMie
streser - 30 wrz 2009, o 12:08 Jestem ciekaw Waszych opini na temat tego jak powinien wyglądać proces testowy w SCRUM? Spotkałem się z opiniami, że dla porcesu testowego w projektcie scrumowym powinny być tworzone oddzielne sprinty testowe, w których oddzielny zespół testerów - niezależny od developerów testuje daną iteracje. Moim zdaniem mija się to z celem iteracyjnego modelu wytwarzania oprogramowania, gdzie najważniejszy jest czas... U nas w firmie dążymy do tego by proces testowy był w jak największym stopniu zautomatyzowany więc testerzy, a raczej inżynierowie testów mają oddzielne zadania stworzenia testów dla aplikacji, a później dla każdego ficzera jest zadanie by rozbudować testy tak by testowały też ten ficzer, bądź poprawić już istniejące. Oczywiście mowa o testach funkcjonalnych typu Selenium etc. Unity, testy Funkcjonalne, czy Integracyjne są by default dodawane do każdego zadania w sprincie. A jak to powinno wg. Was wyglądać? marek dikta - 14 lis 2009, o 23:45 Witam, U mnie wygląda to podobnie. Najważniejsza sprawa â jeśli chodzi o testy w Scrumie - to automatyzacja. Wprowadzając Scruma do firmy, trzeba możliwie najszybciej zautomatyzować testy tzw. starej, czyli już istniejącej funkcjonalności. Testy automatyczne dla nowych funkcjonalności â zarówno funkcjonalne jak i niefunkcjonalne - powinni na bieżąco dopisywać inżynierowie testów w ramach sprintu developerskiego. Zgadzam się również, że nie powinno być osobnych teamów ani sprintów tzw. testowych. Taka praktyka, przypomina pogoń za własnym ogonem. Wyglądałoby to mniej więcej tak : Testerzy znajdują jakieś błędy, które następnie trafiają w formie przerwań do teamu developerskiego, który w tym czasie zajmuje się już zupełnie czym innym!, następnie re-testy jako przerwania w teamie testerów, który dawno âźzapomniałâ już o zgłoszonym błędzie i zajmuje się już zupełnie czym innym! Nie wspominając o sytuacjach, kiedy trafi się jakiś âźbug - blockerâ i testerzy czekają na poprawki robione w teamie developerskim i tracą czas - itd., itd. Kiedy na jednym z meetingów, przez pomyłkę użyłem w rozmowie z Jeffem Sutherlandem zwrotu âźteam testerówâ â a był to okres transformacji w naszej firmie, kiedy wprowadzaliśmy dział SQA i użyłem tego określenia z rozpędu, właśnie w odniesieniu do naszego SQA â musiałem się długo i tęgo tłumaczyć ze swojej pomyłki, że nie mamy żadnego âźteamu testerówâ . W sprintach developerskich na trzech developerów powinien przypadać jeden tester, który przetestuje nowe âźficzeryâ oraz dopisze do nich funkcjonalne i niefunkcjonalne testy automatyczne. Zakończony sukcesem sprint, w połączeniu z pozytywnym raportem z testów automatycznych âźstarej funkcjonalnościâ powinien dać nam spokojnie wersję co najmniej âźrelease candidateâ a nawet âźreleaseâ â zależnie o specyfiki produkowanego softwaru. pozdrawiam serdecznie lukaszow - 5 gru 2009, o 18:08 Jeśli celem sprintu miało by być przetestowanie aplikacji (np. jakiegoś modułu/ów) to oczywiście można stworzyć osoby sprint. Jednak nie wyobrażam sobie takiego celu, chyba, że jakiś moduł aplikacji rzeczywiście jest tak skomplikowany, że testowanie jego to tak naprawdę pisanie oprogramowania testowego i jego uruchomienie. U nas w projekcie były np. testy wydajnościowe, gdzie musieliśmy napisać osobny soft (był określony cel testów). Sprint powinien zawierać na wejściu wymagania, np. listę funkcjonalności, na wyjściu GOTOWE funkcjonalności. GOTOWE czyli również przetestowane. Takie podejście wywodzi się ze źródeł Agile. Jedną z 14 zasad Toyoty w tej kwestii jest "przepływ jednej sztuki", czyli możliwie krótki czas od podpisania umowy do oddania produktu. Polecam książkę "Toyota way". P.S. Jeśli ktoś ma ochotę to zapraszam na szkolenie pod koniec stycznia 2010 we Wrocławiu http://www.semibit.com. Szkolenie prowadzone jest przez certyfikowanego trenera Scrum.
|