Temat: Ile automatyzacji w Agile?

TDD, ATDD, Continuous Integration? Testy automatyczne dla kaażdej User Story czy tylko dla tych z największym ryzykiem? Co robicie, co polecacie?

Temat: Ile automatyzacji w Agile?

Ponieważ automatyzacja sama w sobie jest kosztowna, to zachowałbym jakiś zdrowy rozsądek. Automatyzacja tak, ale na pewno nie dla wszystkich User Stories.

Ja bym proponował automatyzować raczej testy procesów biznesowych, niż pojedynczych User Story. A jeśli procesy nie są bardzo skomplikowane, to ewentualnie tylko te User Story, które mają najwięcej zależności od i do innych User Story.

W przypadku gdy User Stories są od siebie niezależne (raczej mało prawdopodobne), to w ogóle nie polecałbym automatyzacji - szkoda energii.

Temat: Ile automatyzacji w Agile?

Rozpisać najpierw scenariusze testowe, przanalizować i automatyzować na podstawie budżetu i ekonomii.

Reasumując, automatyzować to, co się opłaca automatyzować, a nie wszystko się opłaca.Tomasz Grzechowski edytował(a) ten post dnia 16.04.12 o godzinie 16:34

Temat: Ile automatyzacji w Agile?

Łukasz Baiński:

Ja bym proponował automatyzować raczej testy procesów biznesowych, niż pojedynczych User Story.

Każda User Story powinna mieć wartość biznesową. Co rozumiesz przez procesy biznesowe?

A jeśli procesy nie są bardzo skomplikowane, to ewentualnie tylko te User Story, które mają najwięcej zależności od i do innych User Story.

Biorąc pod uwagę model INVEST, to Story powinny by niezależne.

W przypadku gdy User Stories są od siebie niezależne (raczej mało prawdopodobne), to w ogóle nie polecałbym automatyzacji - szkoda energii.

No to jak robisz testy regresji?

Temat: Ile automatyzacji w Agile?

Tomasz Grzechowski:
Rozpisać najpierw scenariusze testowe, przanalizować i automatyzować na podstawie budżetu i ekonomii.

Ile zajmuje w Sprincie takie rozpisanie i analiza?

Reasumując, automatyzować to, co się opłaca automatyzować, a nie wszystko się opłaca.

Skąd wiesz co się opłaca? Szacujesz wartość bugów, których można uniknąć?

Temat: Ile automatyzacji w Agile?

Krystian K.:

Łukasz Baiński:

Ja bym proponował automatyzować raczej testy procesów biznesowych, niż pojedynczych User Story.

Każda User Story powinna mieć wartość biznesową. Co rozumiesz przez procesy biznesowe?

Rzeczywiście skrót myślowy, który nie do końca jest jasny. Dla mnie proces biznesowy składa się z zestawu powiązanych ze sobą User Story. Przykład procesu (w dużym uproszczeniu) z systemu jaki w ten sposób razem ze swoim teamem tworzyłem:
Klient wypełnia formularz danych osobowych -> Klient wypełnia ankietę oceny ryzyka -> System generuje strategię inwestycyjną -> Klient akceptuje strategię -> Klient prosi o kontrakt -> Pracownik Operacji generuje dokumenty kontraktowe, ...

A jeśli procesy nie są bardzo skomplikowane, to ewentualnie tylko te User Story, które mają najwięcej zależności od i do innych User Story.

Biorąc pod uwagę model INVEST, to Story powinny by niezależne.

I jak najbardziej są w mojej nomenklaturze niezależne:
US1. Jako Klient składam zlecenie wypłaty środków
US2. Jako Klient przeglądam listę aktywnych dyspozycji wypłaty
Są one zgodne z modelem INVEST (i te powyżej z przykładu procesu też), ale patrząc z punktu widzenia przepływu danych, to od wyniku US1 zależy wynik US2.

W przypadku gdy User Stories są od siebie niezależne (raczej mało prawdopodobne), to w ogóle nie polecałbym automatyzacji - szkoda energii.

No to jak robisz testy regresji?

Testy regresji w Unit Testach i zautomatyzowanych testach procesów.

Temat: Ile automatyzacji w Agile?

Krystian K.:

Tomasz Grzechowski:
Rozpisać najpierw scenariusze testowe, przanalizować i automatyzować na podstawie budżetu i ekonomii.

Ile zajmuje w Sprincie takie rozpisanie i analiza?

pomijam słówko Sprint, bo trudno mi się do niego odnieść w kontekście pytania

rozpisanie scenariuszy, zależy od złożoności aplikacji, dla takiej aplikacji (zakładając jej znajomość), można to zrobić w 1-2 dni : http://mysurveylab.com/

Takie scenariusze dzielimy na grupy, np.

1. Rejestracja, aktywacja, logowanie (ma poniżej 10 testów)
2. Konto i zarządzanie (ma poniżej 20 testów)
3. Budowa ankiety
4. Budowa testu

etc...

Nadajemy odpowiednie symbole (grupom) i numery testom, także np. test ma w końcu symbol : MSL-UA-03

Pojedynczy test (historyjka testowa), to jedno zdanie, w nawiasach dodajemy szczegóły, jeśli jest proces krokowy (wyrażenia nie zdania, np. formularz, mail, potwierdzenie), oprócz tego testy mogą się ze sobą łączyć, wtedy w nawiasie jest lista testów współzależnych (bo np. proces jest złożony)

W ten sposób możemy ustalać w trakcie developmentu które elementy wymagają testowania przed publikacją, lista symboli grup lub pojedynczych testów.

Reasumując, automatyzować to, co się opłaca automatyzować, a nie wszystko się opłaca.

Skąd wiesz co się opłaca? Szacujesz wartość bugów, których można uniknąć?

Raczej stosunek czasu jaki spędzamy na testowaniu, do czasu który spędzimy na implementacji automatyzacji.

Temat: Ile automatyzacji w Agile?

Tomasz Grzechowski:

Krystian K.:

Tomasz Grzechowski:
Rozpisać najpierw scenariusze testowe, przanalizować i automatyzować na podstawie budżetu i ekonomii.

Ile zajmuje w Sprincie takie rozpisanie i analiza?

pomijam słówko Sprint, bo trudno mi się do niego odnieść w kontekście pytania

No właśnie to słowko jest bardzo ciekawe. Kiedy i jak testy są automatyzowane w trakcie Sprintu.

Raczej stosunek czasu jaki spędzamy na testowaniu, do czasu który spędzimy na implementacji automatyzacji.

No to kiedy się opłaca? Jaki musi być stosunek?

Temat: Ile automatyzacji w Agile?

Łukasz Baiński:

I jak najbardziej są w mojej nomenklaturze niezależne:
US1. Jako Klient składam zlecenie wypłaty środków
US2. Jako Klient przeglądam listę aktywnych dyspozycji wypłaty
Są one zgodne z modelem INVEST (i te powyżej z przykładu procesu też), ale patrząc z punktu widzenia przepływu danych, to od wyniku US1 zależy wynik US2.

Ok. Dzięki za rozwinięcie.
Zatem automatyzujesz US1 i potem US2 czy czekasz na implementację obu i automatyzujesz US1 i US2 na raz?

Temat: Ile automatyzacji w Agile?

Krystian K.:
No właśnie to słowko jest bardzo ciekawe. Kiedy i jak testy są automatyzowane w trakcie Sprintu.

Nie jestem ekspertem Scrum, ale skoro pytasz zakładam, że już pogooglałeś i nigdzie tego nie napisali.

Skoro Scrum jest Agile, więc zakładam, że pozostawia dość sporo miejsca na decyzje developera.

IMHO developer powinien zawsze przekazywać program do odbioru o jak najwyższej jakości.

Testowanie w trakcie iteracji/sprintu (postawię, tu znak równości mimo, że są różnice), powinno zatem być wykonywane przez developera (ów?) tak często jak mu (im?) to jest potrzebne.

Tak czy inaczej, po zakończeniu dużej iteracji (etapu developerskiego np. milestone/wersji), należy dokonać kompletnego testu elementów powiązanych z procesem developerskim, testy te powinny być wykonane przez inną osobę w zespole. Najlepiej gdy jest to w ogóle specjalista testowania, ale nie zawsze jest to możliwe (ekonomia :-)).

Raczej stosunek czasu jaki spędzamy na testowaniu, do czasu który spędzimy na implementacji automatyzacji.

No to kiedy się opłaca? Jaki musi być stosunek?

To już nie wynika z pojedynczej iteracji, ale taką decyzję powinien podejmować zespół na podstawie doświadczeń.

Wydaje mi się, że nie ma tu jednoznacznej odpowiedzi. Są różne projekty, różne budżety i różne zespoły. Jeśli automatyzacja testowania, przyśpieszy w efekcie proces produkcyjny, to jest to decyzja właściwa z punktu widzenia ekonomii. Ale jeśli implementacja testów zajmie 100h a Ty nie masz na to budżetu, bo musisz budować, to jest to również decyzja właściwa z punktu widzenia ekonomii, mimo, że przez to budujesz mniej wydajnie.

:-)Tomasz Grzechowski edytował(a) ten post dnia 21.04.12 o godzinie 11:28

Temat: Ile automatyzacji w Agile?

Krystian K.:

Ok. Dzięki za rozwinięcie.
Zatem automatyzujesz US1 i potem US2 czy czekasz na implementację obu i automatyzujesz US1 i US2 na raz?

Jeśli w sprincie mieści się cały proces, to oczywiście jest on w całości automatyzowany. Jeśli udaje się tylko poszczególne User Story, to w ramach sprinta powstają do nich automatyczne testy, a jak zaimplementowany będzie ostatni US w procesie, to automatyzowany jest proces (czyli dorabiana jest automatyzacja powiązań pomiędzy US).

Temat: Ile automatyzacji w Agile?

Łukasz Baiński:

Jeśli w sprincie mieści się cały proces...

To mi nasuwa na myśl podstawowe pytanie: Co jest w Definition of Done?
Pytanie dodatkowe: Jak zatem szacowane są aktywności testowe na Sprint Planning Meeting?

Temat: Ile automatyzacji w Agile?

Krystian K.:

Łukasz Baiński:

Jeśli w sprincie mieści się cały proces...

To mi nasuwa na myśl podstawowe pytanie: Co jest w Definition of Done?
Pytanie dodatkowe: Jak zatem szacowane są aktywności testowe na Sprint Planning Meeting?

Napewno w denfinicji Done jest jakaś wzmianka, że element product back logu jest sprawdzony- tzn. że działa wg. założeń. Wg. mnie definiowanie sposobu, którym to zapewniamy (czy to przez testy manualne czy automatyczne, czy jeszcze inaczej) jest w tym wypadku mniej istotne.

Co do drugiego pytania, to nie wiem czy są w ogóle szacowane:) Poziom złożoności testów jest mocno zależny od skomplikowania rozwiązani z jednej strony,a z drugiej czasem drobna zmiana w kodzie wymaga intensywnych testów. Zatem zapewne szacowania zależą od funkcjonalnej strony produktu i ilości ścieżek (pozytywnych i alternatywnych) jakie można "wyobrazić" sobie w momencie planowania, dla zakresu projektu realizowanego w sprincie.

Temat: Ile automatyzacji w Agile?

Marcin Złotowicz:

Pytam PZU, Allegro mi odpowiada. Masz dobre pomysły, ale zobaczmy jak to robi ten specyficzny team.
A skoro już jesteś, to jak to tam z automatyzacją u Ciebie? Jakieś zasady, cześć Definition of Done, narzędzia, metryki?

Temat: Ile automatyzacji w Agile?

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

Definition of Done dla każdego teamu będzie inne. Chodzi o to, żeby każdy mówiąc zrobione rozumiał to samo. Poza tym, ta definicja w trakcie projektu może ewoluować i zależeć od tego czy budujemy system gdzie jest więcej GUI czy więcej logiki biznesowej i procesów systemowych.

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.

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. 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ł ;)

Krystian K.:

Marcin Złotowicz:

Pytam PZU, Allegro mi odpowiada. Masz dobre pomysły, ale zobaczmy jak to robi ten specyficzny team.
A skoro już jesteś, to jak to tam z automatyzacją u Ciebie? Jakieś zasady, cześć Definition of Done, narzędzia, metryki?

Temat: Ile automatyzacji w Agile?

Heh, nie zauważyłem ze pytanie jest kierowane tylko do kolegi. Po drugie piszę w swoim imieniu;
Co do automatyzacji, wszystko jest na miejscu. Automaty, metryki etc. Nie jestem fanem formalnych wymagań co do ilości i pokrycia automatów, bo rodzi to czasem patologie. Tak jak wcześniej napisalem definicja done nie powyinna zawierać odnośników do narzędzi czy technik których używamy. Narzędzia głównie standardowe.Marcin Złotowicz edytował(a) ten post dnia 27.07.12 o godzinie 18:58

Temat: Ile automatyzacji w Agile?

Tak, patologii nie lubimy. :)

Marcin Złotowicz:
wszystko jest na miejscu
Narzędzia głównie standardowe

Może trochę więcej szczegółów? :)

Temat: Ile automatyzacji w Agile?

Ł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ć.
Już z dwa lata temu rozmawiałem z PO, która była na w projekcie przechodzącym an Scrum. Nadal przejście się nie udało?

Definition of Done dla każdego teamu będzie inne. Chodzi o to, żeby każdy mówiąc zrobione rozumiał to samo. Poza tym, ta definicja w trakcie projektu może ewoluować i zależeć od tego czy budujemy system gdzie jest więcej GUI czy więcej logiki biznesowej i procesów systemowych.

Prawda.

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". :)

Co na to test plan i analiza ryzyka?

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?

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.

Temat: Ile automatyzacji w Agile?

Krystian K.:
Tak, patologii nie lubimy. :)

Marcin Złotowicz:
wszystko jest na miejscu
Narzędzia głównie standardowe

Może trochę więcej szczegółów? :)

Narzędzia do automatyzacji to Selenium + własny framework. 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).
Metryki służą głównie do ogarnięcia stanu poszczególnych skryptów i ich jakości. Jak często fail-ują, z jakiego powodu, etc.

Temat: Ile automatyzacji w Agile?

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?

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

Metryki służą głównie do ogarnięcia stanu poszczególnych
skryptów i ich jakości. Jak często fail-ują, z jakiego powodu, etc.