Temat: Ile automatyzacji w Agile?

Krystian K.:

Łukasz Baiński:
W PZU rządzi PRINCE :)
Moje doświadczenia agile'owe są w 100% z firmy BMS.

Można PRINCE z Agile łączyć.

I tak i nie :) To generalnie temat na osobną dyskusję, jeśli ktoś ma ochotę - to proponuję w osobnym wątku.

Ja bym proponował przyjąć następującą definicję skończonego US: przechodzą wszystkie zdefiniowane dla niego testy automatyczne. Jeżeli mamy zbudowany już cały proces składający się z kilku US, to przechodzą testy automatyczne procesu.

O, i to jest całkiem rozsądne. Rozumiem, że póki co rozważania teoretyczne? Co by było można i co jest dobre to można się dowiedzieć na szkoleniu albo z książki. Proponuję podzielić się tutaj bardziej doświadczeniem z "pola walki". :)

To jak najbardziej doświadczenia z pola walki. Na początku projektu, gdy mieliśmy niewiele automatyzacji, Done oznaczało: przechodzą wszystkie testy jednostkowe w danym US, tester potwierdzał na podstawie manualnych testów. Następnie budowane były testy automatyczne do US, a następnie do procesów, Done zmieniało się jak to opisałem poprzednio.

Co na to test plan i analiza ryzyka?

Nie bardzo rozumiem pytanie, mógłbyś doprecyzować?

Co do szacowania na Sprint Planning, to odbywa się to podobnie jak z szacowaniem US, czyli szacowanie eksperckie.
Dużo trudniej jest oszacować nakłady potrzebne na testy na etapie budowania i szacowania backolgu.

Tak samo jak trudno szacować development na tym etapie. Najłatwiej przez odniesienie do tego co już się robiło. Mniejsze czy większe niż X? O ile?

Zgadzam się, że na początku projektu wszystko się trudno szacuje, a błąd jest duży. U mnie wyglądało to tak (development), że pierwsze szacowanie (eksperckie w MD) robił architekt. Kluczowe jest tu moim zdaniem jasne opisanie założeń przy jaki się szacuje. Następnie zespół szacował przy pomocy planning pokera (w abstrakcyjnych punktach). Punkty przeliczaliśmy na MD w ten sposób, że najmniejsze US za 1 punkt rozbijane było na niskopoziomowe zadania i szacowane w MD, potem proste mnożenie, iiii.... wszystko się rozjeżdża w kosmos :) Ostatni krok, to skalowanie szacunków w punktach i eksperckie i dojście do jakiegoś sensownego kompromisu.

Z szacowaniem automatyzacji było o tyle trudniej, że mieliśmy jednego testera, więc planning poker i inne tego typu narzędzia szacowania zespołowego nie wchodziły w grę. Trzeba się było oprzeć o szacunki eksperckie i ograniczenia budżetowe / kontaktowe.

Jak powiadał jeden z bardziej doświadczonych kolegów, potrzebny jest jeden tester (taki co to potrafi pisać testy automatyczne) na 3 developerów. Czy to dobre oszacowanie? Powiem tak - jeden tester na 6 developerów nie wystarczył ;)

Prawidłowa odpowiedź to "Zależy". nie ma wzoru i reguły. Wszystko zależy od domeny, poziomu zespołu, jakości wymagań, ryzyka, standardów i norm, itd.

Zgadzam się. Fajnie, że dodajesz od razu część 'od czego zależy' :)

Temat: Ile automatyzacji w Agile?

Krystian K.:

Marcin Złotowicz:

Narzędzia do automatyzacji to Selenium + własny framework.

Selenium z WebDriver czy Selenium-RC? Było przechodzenie z Selenium-RC na WebDriver?

I SeleniumRC i WebDriver. Z doświadczenia wynika, że selenium radzi (radziło?) sobie czasami lepiej z pewnymi aplikacjami/elementami/akcjami niż WebDriver. Choć z każdym kolejnym releasem Selenium różnice się zmniejszają i obecnie wygaszamy Selenium 1.0. Akcji przejścia jakiejś mega nie było, zbyt kosztowne, raczej w czasie zwykłego utrzymania, gdy skrypt nie domaga to przepisujemy na WD. W myśl zasady: "Jeżeli coś działa po co to zmieniać".
Czy spotkałeś się z jakąś większą migracją z RC na WD? Opłacało się?

Dzielimy automaty na dwa rodzaje, "zwykłe" - implementujące przypadki testowe, oraz budowane w oparciu o BDD (polecam w tym miejscu fajne narzędzie: SpecFlow).

Czy jako "zwykłe" rozumiane są przypadki pochodzące z technik testowania? Np. BVA

Tak, dokładnie, choć wtedy zwykle łączymy w jednym skrypcie kilka technik, by wykorzystując raz zaimplementowaną logikę zmieniać tylko dane i ew. oczekiwane wyniki.

Temat: Ile automatyzacji w Agile?

Łukasz Baiński:

Co na to test plan i analiza ryzyka?

Nie bardzo rozumiem pytanie, mógłbyś doprecyzować?

Czy Test Plan mówił coś o automatyzacji? Czy automatyzacja User Stories zależała od poziomu ryzyk?

Zgadzam się, że na początku projektu wszystko się trudno szacuje, a błąd jest duży. U mnie wyglądało to tak (development), że pierwsze szacowanie (eksperckie w MD) robił architekt. Kluczowe jest tu moim zdaniem jasne opisanie założeń przy jaki się szacuje. Następnie zespół szacował przy pomocy planning pokera (w abstrakcyjnych punktach). Punkty przeliczaliśmy na MD w ten sposób, że najmniejsze US za 1 punkt rozbijane było na niskopoziomowe zadania i szacowane w MD, potem proste mnożenie, iiii.... wszystko się rozjeżdża w kosmos :) Ostatni krok, to skalowanie szacunków w punktach i eksperckie i dojście do jakiegoś sensownego kompromisu.

Jej, skomplikowane to i zakręcone jak baranie rogi. :)
Co to MD?

Temat: Ile automatyzacji w Agile?

Marcin Złotowicz:

Czy spotkałeś się z jakąś większą migracją z RC na WD? Opłacało się?

Nie spotkałem się w praktyce. Miałem taki plan i z takim setup-em jak mieliśmy wtedy powinna to być dosyć bezbolesna migracja. Na pewno nigdy nie wiesz. Prawa Murphiego tylko czekają, żeby zadziałaś w takiej sytuacji.

Tak, dokładnie, choć wtedy zwykle łączymy w jednym skrypcie kilka technik, by wykorzystując raz zaimplementowaną logikę zmieniać tylko dane i ew. oczekiwane wyniki.

I o to chodzi! :)

Temat: Ile automatyzacji w Agile?

Krystian K.:

Łukasz Baiński:

Co na to test plan i analiza ryzyka?

Nie bardzo rozumiem pytanie, mógłbyś doprecyzować?

Czy Test Plan mówił coś o automatyzacji? Czy automatyzacja User Stories zależała od poziomu ryzyk?

Bardziej określiłbym to jako zbiór założeń niż Plan Testów :) Ale tak - z góry zakładana była automatyzacja i zdecydowanie zależała od poziomu ryzyka. DO testów automatycznych wybierane były najbardziej skomplikowane elementy systemu, a zarazem te US, które posiadały najwięcej zależności 'od' i 'do' innych US (o tym pisałem już trochę na początku wątku).

Zgadzam się, że na początku projektu wszystko się trudno szacuje, a błąd jest duży. U mnie wyglądało to tak (development), że pierwsze szacowanie (eksperckie w MD) robił architekt. Kluczowe jest tu moim zdaniem jasne opisanie założeń przy jaki się szacuje. Następnie zespół szacował przy pomocy planning pokera (w abstrakcyjnych punktach). Punkty przeliczaliśmy na MD w ten sposób, że najmniejsze US za 1 punkt rozbijane było na niskopoziomowe zadania i szacowane w MD, potem proste mnożenie, iiii.... wszystko się rozjeżdża w kosmos :) Ostatni krok, to skalowanie szacunków w punktach i eksperckie i dojście do jakiegoś sensownego kompromisu.

Jej, skomplikowane to i zakręcone jak baranie rogi. :)

Tylko za pierwszym razem :) Tak naprawdę, to można by to uogólnić do szacowania eksperckiego (najczęściej na etapie procesu sprzedażowego), a następnie werfyfikacji tych szacunków dowolną metodą szacowania zespołowego.

Co to MD?

Man Days