Temat: [crosspost]Jak, bez uzycia Unit Testow, zapewnic QA w...

Grzegorz Świeć:
No wlasnie, firma w ktorej pracuje chce wprowadzic role testera w projektach prowadzonych metodologia Agile Scrum.(...) Powstaje wiec pytanie w jaki sposob zorganizowac prace testera tak by po pierwsze byl on skuteczny, po drugie - oprocz scislej komunikacji nie obciazal dodatkowa praca developerow przy tworzeniu testow.

SCRUM nie przewiduje testera jak budowy modeli :). Myślę, że jedno i drugie da się zrobić. W przypadku "SCRUM Testera" to jego robota nie rożni się od tradycyjnego działania. I nie jest to istotne czy będzie miał nakazane robić testy wydajnościowe czy akceptacyjne czy inne. Wyniki jego prac powinny być zapisywane do Backloga lub do Sprint Backloga lub Task Board. Miejsce zapisania wynika z rodzaju i wielkości błędu i zazwyczaj ustala się go na codziennych scrumach.
W ten sposób nie obciąża developerów mówi im tylko co mają poprawić :)

Natomiast jeśli chcesz by tester grzebał w kodzie celem pisania testów to nie wróżę takiemu rozwiązaniu powodzenia.

Dwa słowa o testach w Task Board można znaleźć tutaj.Michał Wolski edytował(a) ten post dnia 09.07.09 o godzinie 22:10

Temat: [crosspost]Jak, bez uzycia Unit Testow, zapewnic QA w...

Michał Wolski:

SCRUM nie przewiduje testera jak budowy modeli :).

Jaśniej proszę.

Myślę, że jedno i drugie da się zrobić. W przypadku "SCRUM Testera" to jego robota nie rożni się od tradycyjnego działania.

Różni się i to bardzo, bo w waterfallu wiadomo kiedy development się zakończył i tester może zacząć pracę. W Scrum środowisko może być niestabilne, feature'y zależne od kilku tasków. Scrum Tester, czy też szerzej Agile Tester ma o wiele cięższe zadanie, bo musi tak współpracować z developerami, żeby zapewnić testowanie jako cześć definicji DONE. Często też tester planuje testy razem z developerami.
>I nie jest

to istotne czy będzie miał nakazane robić testy wydajnościowe czy akceptacyjne czy inne. Wyniki jego prac powinny być zapisywane do Backloga lub do Sprint Backloga lub Task Board. Miejsce zapisania wynika z rodzaju i wielkości błędu i zazwyczaj ustala się go na codziennych scrumach.

Wyniki jego pracy są zapisywane raczej w bazie defectów i raportach z testów. Do Sprint Backlog dodawane są bugi, które nie pozwalają, żeby task był DONE, albo przesuwamy task z powrotem do developmentu, bo nie jest zakończony. Osobiście wolę tą drugą metodę, żeby nie sugerować, że bug fix można przesunąć na następny Sprint albo zrobić w "czasie pomiędzy Sprintami". Do tego dochodzi też kwestia jak planujemy testy? Jako część zadania i zadanie jest przejmowane przez testera, czy jako osobny task.
Jaka jest różnica między Sprint Backlog a Task Board? :)

W ten sposób nie obciąża developerów mówi im tylko co mają poprawić :)

Natomiast jeśli chcesz by tester grzebał w kodzie celem pisania testów to nie wróżę takiemu rozwiązaniu powodzenia.

Tester pisząc Unity nie powinien ingerować w kod i nie powinna istnieć taka konieczność. Jeśli tak jest, to kod nie jest wystarczająco testowalny. Unit Testy zwykle są w osobnym katalogu, więc nikt nikomu nie psuje.

Dwa słowa o testach w Task Board można znaleźć tutaj

Zbieżność nazwisk to przypadek czy lekka autopromocja? :)

Temat: [crosspost]Jak, bez uzycia Unit Testow, zapewnic QA w...

Hej,

Test Driven Design... faktycznie, rzadko się spotyka, ale po szybkim googlowaniu... jest to inna nazwa na test driven development :)

Ja widzę testowanie w agile teamie jako jedną z dwóch opcji (tzn chce miec obie w zespole).
1. Programiści piszą kod i testy - każdy commit/push funkcjonalności zawiera kod funkcjonalności i testów. Wybór programisty czy pisze TDD (najpierw testy - potem kod), czy na odwrót. W praktyce widzę, że przeważnie się pisze równolegle - np testy ogólne na początek, a później po jednym unicie do każdej implementowanej metody. Tutaj raczej nie wyróżniałbym osoby od pisania testów. Zespół agile nie ma podziału na role i sam dzieli się zadaniami.

2. QA - czyli testerzy "klikający" w skomitowany kod, w trakcie lub po zakonczeniu sprintu. W web-developmecie sprawdzają czy aplikacja działa i wygląda na różnych przeglądarkach i systemach. W aplikacjach instalowanych - sprawdzają czy dziła na różnych systemach i sprzęcie.

3. Znacząco innych opcji wewnątrz zespołu agile nie widziałem nigdy na żywo. Jak ktoś widział/prowadził taki zespół to niech opowie o doświadczeniach :)

Tak czy siak klient, z reguły ma swoich testerów w tej czy innej postaci. Pisanie testów akceptacyjnych z góry w agile jest raczej skazane na porażkę, bo na początku przecież i tak nikt nie wie co będzie na końcu :)

Nie jestem zwolennikiem podejścia - ludzi od czarnej roboty (testów lub html'a css'a). Mija się to z inną ideą agile - każdy programista może zamienić się z innym w dowolnym momencie (taki ortodox to już chyba tylko w XP, ale fajnie mieć taką możliwość w zespole)

MarekMarek Kirejczyk edytował(a) ten post dnia 10.07.09 o godzinie 19:06

Temat: [crosspost]Jak, bez uzycia Unit Testow, zapewnic QA w...

Krystian K.:

Michał Wolski:

SCRUM nie przewiduje testera jak budowy modeli :).

Jaśniej proszę.

Chodziło mi o to, że standardowo nie buduje się modeli UML w trakcie budowy systemu zgodnie ze Scrum.

Myślę, że jedno i drugie da się zrobić. W przypadku "SCRUM Testera" to jego robota nie rożni się od tradycyjnego działania.

Różni się i to bardzo, bo w waterfallu wiadomo kiedy development się zakończył i tester może zacząć pracę. W Scrum środowisko może być niestabilne, feature'y zależne od kilku tasków. Scrum Tester, czy też szerzej Agile Tester ma o wiele cięższe zadanie, bo musi tak współpracować z developerami, żeby zapewnić testowanie jako cześć definicji DONE. Często też tester planuje testy razem z developerami.

I tu się z Tobą nie zgodzę. Moim zdaniem lepszym rozwiązaniem są testy planowane bez udziału developerów. Można to osiągnąć stosując wspomniane przeze mnie modele UML. Wtedy wcześniej jest wiadomo od jakich tasków zależą poszczególne feature'y. Mniej przypadkowości. Oczywiście ja nie mówię tu od ortodoksyjnym Agile, w którym modele nie istnieją. To co to proponuję nazywam zwinnym modelowaniem (Agile Modeling) i ma niewiele wspólnego z ciężkimi topornymi metodykami :)Michał Wolski edytował(a) ten post dnia 12.07.09 o godzinie 23:05

Temat: [crosspost]Jak, bez uzycia Unit Testow, zapewnic QA w...

Właściwie postem Marka można zamknąć temat, więc przejdę do offtopu ;)

Krystian K.:
Różni się i to bardzo, bo w waterfallu wiadomo kiedy development się zakończył i tester może zacząć pracę.

To chyba w jakimś mitycznym waterfallu, bo zasadniczo (nawet w waterfallu) rozpoczęcie pracy przez testera oznacza skończenie przez developerów mniej-więcej połowy swojej pracy.
Tej łatwiejszej połowy ;)

Temat: [crosspost]Jak, bez uzycia Unit Testow, zapewnic QA w...

Tomasz Stachewicz:
To chyba w jakimś mitycznym waterfallu, bo zasadniczo (nawet w waterfallu) rozpoczęcie pracy przez testera oznacza skończenie przez developerów mniej-więcej połowy swojej pracy.
Tej łatwiejszej połowy ;)

No to wrzuć tutaj jakiś ładny diagram ilustrujący te 50% w waterfallu. :)

Temat: [crosspost]Jak, bez uzycia Unit Testow, zapewnic QA w...

O diagram się nie pokuszę, ale czym jest faza debugowania po/w trakcie fazy testów, jeśli nie pracą programistów co najmniej tak samo dużą jak "pierwsze napisanie"? ;)