Testarea in SCRUM
Lucian Daniliuc
Avand in vedere ca:
(1) echipa ar trebui sa fie omogena (or testerul nostru e doar foarte
bun tester) si
(2) mai mult de jumatate din sprint dezvoltatorii rezolva taskurile
iar user-story-urile inca nu sunt testabile,
rezulta si nedumerirea mea: cum ar trebui sa se desfasoare activitatea
testerului ca sa fie in spiritul Agile ?
Lucian Daniliuc
Maria Diaconu
- Testerul participa la planning&estimation meetings la fel ca si dezvoltatorii, web-designers, analysts, etc. Trebuie sa inteleaga foarte bine user-story-urile de implementat, sa ridice intrebari referitoare la ce probleme reale rezolva acele user-stories, sa priveasca lucrurile nu numai ca tester dar si ca end-user al aplicatiei (in functie de tipul aplicatiei, daca este posibil acest lucru). Estimeaza alaturi de echipa, se implica in discutia de argumentare atunci cand sunt diferente in estimari - avantajul este prezenta unui alt mod de gandire decat cel al programatorilor.
- In prima parte a iteratiei, in timp ce programatorii implementeaza user-stories, testerul se gandeste si scrie scenarii de test - atat pentru user-story-urile punctuale, cat si pentru "flow"-ul din care fac parte; poate sa revina cu intrebari al ProductOwners daca descopera neclaritati - uneori descopera inaintea programatorilor ca lipsesc anumite informatii sau exista probleme in logica cerintelor sau poate face "pair" cu programatorii sau designerii pentru gasirea unor solutii practice (ex: din punct de vedere UX)
- Imediat ce este implementat un user story sau un set de user stories, testerul va verifica aplicatia, adauga noi scenarii de test daca este cazul sau le modifica pe cele existente; este indicat sa faca "pair" daca descopera inadvertente serioase - discutia "face-to-face" va clarifica mult mai rapid si cu o intelegere mai buna decat daca va scrie mai intai "the issue" intr-un tool automat
- Tester-ul participa la Daily Meeting la fel ca si programatorii - cu cat se imbunatateste comunicarea intre testeri si programatori, cu atat echipa devine mai productiva (de multe ori prin identificarea problemelor in stadiu incipient si evitarea lor)
- La Review, in cadrul prezentarii catre Product Owners, interventia testerilor poate sa clarifice anumite decizii luate de echipa si sa micsoreze "gap"-ul dintre PO si programatori
- La Retrospectiva si la gasirea unor solutii la problemele existente, testerii pot sa vina cu solutii practice (& pragmatice) pentru aria de verificare (ex: daca user-stories nu sunt testabile in forma actuala, oare nu cumva le putem sparge in user-story mai mici? [de obicei raspunsul programatorilor este "nu"; dar cu putin ajutor de la testeri s-ar putea sa gasim o rezolvare].
--
Agile Romania community founder
www.agileworks.ro - Romanian Agile/Scrum community website
www.openagile.ro
--
You received this message because you are subscribed to the Google Groups "AgileWorks Romania" group.
To post to this group, send email to agilework...@googlegroups.com.
To unsubscribe from this group, send email to agileworks-roma...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agileworks-romania?hl=en.
tsk
e una din caracteristici. Toata lumea face toata treaba. Participa la
analiza continua a cerintelor, dezvolta cod si interfata daca este
cazul si testeaza. De cele mai multe ori se intamla un lucru
considerat de unii funny. Cine are cea mai mare experienta ca tester
ajunge sa coordoneze si sa trainuiasca programatorii in procesul de
testare a story-urilor - dar care se intampla pe tot parcursul
Sprintului.
Bafta.
Radu
Maria Diaconu
adevar, in echipa Scrum nu exista roluri predefinite. Dar intotdeauna
exista competente.
Ceea ce face foarte bine o echipa Scrum este sa transfere aceste
competente in cadrul ei. Ca atare, dezvoltatorii invata sa testeze,
testerii invata sa scrie ceva cod (d.e. scripturi pentru automatizarea
testarii) iar toata echipa invata business-ul aplicatiei si inteleg in
profunzime domeniul problemei.
Adaptabilitatea asta apare in urma lucrului impreuna - unul din
principiile cheie in agile. Din experienta unor echipe Scrum acum
foarte "profficient", exemplele de mai sus au fost o parte din
actiunile care i-a ajutat sa migreze de la lucrul separat, pe roluri,
catre munca in echipa. Cum nu exista retete predefinite, fiecare
echipa trebuie sa isi gaseasca calea si ce i se potriveste mai bine.
Insa, pentru a ne ajuta in cadrul comunitatii, rugamintea catre cei
care lucreaza in echipe Scrum este sa povesteasca cum fac ei (concret
daca se poate :) ) pentru ca fiecare sa invatam si sa ne inspiram din
experientele impartasite.
Spor,
Maria
alex Rosiu
Raspunsul Mariei ma bucura, pentru ca inseamna ca am inceput intr-o
directie corecta.
Pe (nu foarte) lung:
Dupa ani de zile in care dezvoltarea a fost separata de testare, am
unificat cele doua echipe intr-una singura (de fapt cateva subechipe
de 5-6 oameni). Atat inainte de a face acest lucru, dar si la inceput,
ne-am confruntat exact cu intrebarea ce reprezinta subiectul acestei
discutii: "Bine, dar ce vor face testerii cat timp dezvoltatorii...
dezvolta?"
Raspunsul a fost foarte asemanator cu cel dat de Maria, iar acest
lucru spuneam ca ma bucura. De ce am/avem nevoie de aceasta
confirmare? Pentru ca nu e asa simplu cum suna. Nu e simplu pentru ca
presupune mult mai multa implicare din partea tuturor, mult mai multa
disciplina (Agile inseamna multe, printre care si multa disciplina -
intr-un sens bun... nu "armata"), mai mult efort constientizat.
Subliniez "constientizat", pentru ca probabil inainte faceam cel putin
la fel de mult efort, insa de multe ori inconstient si deci,
ineficient.
Momentan suntem si noi la inceputul acestui nou mod de a lucra, insa
este promitator: suntem cu un pas mai aproape ca la finalul fiecarui
sprint sa livram lucruri "done". Fie ca sunt documente de design sau
linii de cod, avem un anume grad de "confidence" in plus, pentru ca
ele sunt acum nu numai testate, dar concepute impreuna cu testerii.
Cel mai important este ca dezvoltatorii incep sa inteleaga (si chiar
ii intereseaza) nevoile testerilor, si invers.
Cel mai mare beneficiu mi se pare deci, schimbarea de mentalitate. De
aici porneste totul.
Numai bine,
Alex.
----------------------------
http://alex.rosiu.eu
On Nov 25, 12:33 pm, Maria Diaconu <mddiac...@gmail.com> wrote:
> Intr-o echipa Scrum, cateva actiuni pentru tester - pe scurt:
>
> - Testerul participa la planning&estimation meetings la fel ca si
> dezvoltatorii, web-designers, analysts, etc. Trebuie sa inteleaga foarte
> bine user-story-urile de implementat, sa ridice intrebari referitoare la ce
> probleme reale rezolva acele user-stories, sa priveasca lucrurile nu numai
> ca tester dar si ca end-user al aplicatiei (in functie de tipul aplicatiei,
> daca este posibil acest lucru). Estimeaza alaturi de echipa, se implica in
> discutia de argumentare atunci cand sunt diferente in estimari - avantajul
> este prezenta unui alt mod de gandire decat cel al programatorilor.
>
> - In prima parte a iteratiei, in timp ce programatorii implementeaza
> user-stories, testerul se gandeste si scrie scenarii de test - atat pentru
> user-story-urile punctuale, cat si pentru "flow"-ul din care fac parte;
> poate sa revina cu intrebari al ProductOwners daca descopera neclaritati -
> uneori descopera inaintea programatorilor ca lipsesc anumite informatii sau
> exista probleme in logica cerintelor sau poate face "pair" cu programatorii
> sau designerii pentru gasirea unor solutii practice (ex: din punct de vedere
> UX)
>
> - Imediat ce este implementat un user story sau un set de user stories,
> testerul va verifica aplicatia, adauga noi scenarii de test daca este cazul
> sau le modifica pe cele existente; este indicat sa faca "pair" daca
> descopera inadvertente serioase - discutia "face-to-face" va clarifica mult
> mai rapid si cu o intelegere mai buna decat daca va scrie mai intai "the
> issue" intr-un tool automat
>
> - Tester-ul participa la Daily Meeting la fel ca si programatorii - cu
> cat se imbunatateste comunicarea intre testeri si programatori, cu atat
> echipa devine mai productiva (de multe ori prin identificarea problemelor in
> stadiu incipient si evitarea lor)
>
> - La Review, in cadrul prezentarii catre Product Owners, interventia
> testerilor poate sa clarifice anumite decizii luate de echipa si sa
> micsoreze "gap"-ul dintre PO si programatori
>
> - La Retrospectiva si la gasirea unor solutii la problemele existente,
> testerii pot sa vina cu solutii practice (& pragmatice) pentru aria de
> verificare (ex: daca user-stories nu sunt testabile in forma actuala, oare
> nu cumva le putem sparge in user-story mai mici? [de obicei raspunsul
> programatorilor este "nu"; dar cu putin ajutor de la testeri s-ar putea sa
> gasim o rezolvare].
>
> Ar mai fi multe de zis, dar las loc sa contribuie si alti membrii ai
> comunitatii.
>
> In incheiere, un "must read" pt acest topic: "Agile Testing: A Practical
> Guide for Testers and Agile Teams", Lisa Crispin & Janet Gregory -http://www.informit.com/store/product.aspx?isbn=9780321534460
>
> --
> Maria Diaconu
> Agile Practitioner | Agile Coach
>
> Agile Romania community founderwww.agileworks.ro- Romanian Agile/Scrum community websitewww.openagile.ro
>
> 2009/11/25 Lucian Daniliuc <dluc...@gmail.com>
>
>
>
> > In echipa SCRUM avem un tester.
>
> > Avand in vedere ca:
>
> > (1) echipa ar trebui sa fie omogena (or testerul nostru e doar foarte
> > bun tester) si
> > (2) mai mult de jumatate din sprint dezvoltatorii rezolva taskurile
> > iar user-story-urile inca nu sunt testabile,
>
> > rezulta si nedumerirea mea: cum ar trebui sa se desfasoare activitatea
> > testerului ca sa fie in spiritul Agile ?
>
> > Lucian Daniliuc
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "AgileWorks Romania" group.
> > To post to this group, send email to agilework...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > agileworks-roma...@googlegroups.com<agileworks-romania%2Bunsubs cr...@googlegroups.com>
Radu Munteanu
Există roluri, echipa Scrum e o echipă mixtă. E Scrum, nu XP. Poate
greesc, dar asta ştiu şi cred eu. E adevărat că unele cunoştinţe sunt
împărţite între membrii, dar nu face programatorul treaba testerului,
cum nici celui care se ocupă de bazele de date nu-i face treaba
programatorul. Dacă se apucă programatorul şi face tot ce face
testerul, o să iasă acelaşi produs care ar fi ieşit fără tester de la
început. Programatorii ar trebui să facă doar unit testing (părerea
mea).
În afară ce a zis Maria, în primul răspuns, adaug şi eu următoarele:
testerul, ca tester nu prea are ce face în prima parte (adică, doar să
studieze decumentaţia, dacă există, să facă scheme de testare şi să ia
parte la planning meetings şi daily scrums), de aia se apucă şi face
şi un pic de QA: ia parte la tot procesul de dezvoltare iniţial,
studiind arhitectura într-o oarecare măsură, venind cu idei legate de
implementare (asta în cadrul altor şedinţe ale programatorilor),
astfel încât să se asigure că soluţia aleasă e cea optimă, în acel
moment. Orice feedback e mai bun decât nici un feedback din partea QA-
ului. După primul sprint o să existe testare de bug fix-uri,
reviewing, astfel încât să aibă testerul ce face de la începutul celui
de-al doilea sprint (dacă chiar nu mai are nimic de făcut). :)
tsk
cross-funtionale. Dimensiunile mici ale unei echipe ideale SCRUM (5-7
membrii fac dificila distribuita rolurilor). In plus prezenta
rolurilor dilueaza mult focusul echipei, responsabilitatea generala
pentru proiect si transforma sprintul intr-o micro-structura waterfall
foarte periculoasa cu timp morti ai diversilor membrii si
responsabilitati particulare care duc la esec.
Sfaturi personale pentru a crea o omogenitate cross-functionala in
cadrul echipei:
- Renunta formal la orice titlu - toti sunt membrii echipei nu
programatori, dba, testeri, arhitecti etc.
- Sanctioneaza drastic prin reguli impuse de comun acord orice
incalcare a acestei reguli (de genul: tu esti tester ce treaba ai tu
cat vorbim despre structura bazei de date).
- Discuta personal si rezolva daca e cazul problemele de respect in
munca. Invata arhitectul (guru programmer) sa respecte programatorii,
invata programatorii sa respecte testeri, invata testerii sa nu-si
indrepte refularile catre programatori samd. Cel mai simplu mod in
care o fac eu este pur si simplu sa-i pun sa faca munca celuilalt si
sa vada programatorul cat de slab este ca tester si ca fara tester nu
ar livra un produs de calitate.
- Daca simti nevoia poti sa emfazezi pozitia de specialist in cadrul
echipei a fiecarei pozitii astfel ca in cadrul sprintului in parte de
testare fostul tester coordoneaza activitatea dar are in subordine
toata echipa cu dba, arhitect, programator etc. Asta va ajuta la
cresterea respectului reciproc si va duce la un grad ridicat de
incredere.
Din punctul meu de vedere, asta e SCRUM, indiferent cat de ciudat
pare, iar implementarea si ajungerea la o echipa performanta nu e ceva
care se intampla peste noapte si fara efort.
Radu
On Jan 5, 8:37 pm, Radu Munteanu <stefan.radu.munte...@gmail.com>
wrote: