Ach boze! Pouzivaji vasi developeri Feture branches? (VBL atp)
...ukocirovat potom ty defekty zalogovane proti VBL, nejak v souladu s tim klicovym prvotnim enhancemetem (take ticket), aby se to pak vsechno nepopralo pri commitu zpet do mainu... To je narez, to jsou procesy! ...to abych ty fixy overoval min 2x...
Co u vas?

RUPIUS: Re na §6: s efektivním využíváním času může pomoci inspirace Critical Chain Project Management - odhady se sází optimisticky, ale čeká se, že zpracování bude trvat o fous dýl. V ideálním případě se to stihne podle odhadu, běžně se ale přetáhne, ale nikdo se kvůli tomu netrápí, páč se s tím počítalo. V projektu jsou tak zvané buffery, které vykrývají časové posuny. Podle této metodologie projekt skončí zpravidla dřív, než se čekalo, protože většinou nejsou využity všechny buffery bezezbytku. Pokud někdo něco blbě odhad, tak se už dost dopředu ví, že se to nestíhá, protože zaplnění bufferů lze velice pěkně sledovat a přesně to vypovídá o tom, jak moc projekt jede podle plánu.

Na to, aby nebyl člověk vyšťavenej, pomůže, že se z pracovní osmičky počítá na čistou práci tak max 5h - ostatní padne na chaos, dočasnou demenci a adhoc-problémy mimo plán a kafíčko. Stejně nikdo nedokáže pravidelně makat osm hodin sto pro (krom kyborgů samozřejmě)

Super odpovedi chlapi! :)

Z vlastni zkusenosti z jedne z ceskych firem vim, ze nejsou veci takove, jakymi se zdaji byt. Vase popisy vypadaji opravdu zajimave a svedci o tom, ze to tam nekdo vede, nebo alespon zavedl procesy a standardy. Pokud jsou pouze zavedene, hrozi, ze by to mohlo dopadnout jako v te jedne firme kde jsem delal...

OASHI: Fakt se mi zalibilo: "Slovo ASAP u nas nema moc vyznam: Bylo by znamkou, ze meni plan, tedy znamkou chaosu", to je fakt super, diky tyhle vete verim, ze jste schopni ve firme vytvorit opravdu kvalitni sw.

Logovani: Zalezi samozrejme na konkretni situaci, ale pokud mozno, testovanim logovani bych spise zacinal. (Ze tveho prispevku jsem mel pocit, jako ze to je okrajova zalezitost... ;) Ale uvedomuju si, ze tomu tak vubec nemusi byt, tak se kdyztak moc necerti :) ) Mit moznost spolehnout se na logy je kazdopadne dalsi a po otestovani verohodny (a tedy zlaty) zdroj informaci.

Prideleni na projekty: Podle toho co pises, mas na starosti dane pridelene feature se vsim vsudy. To je sice hezky, je jednoduche urceni zodpovednosti, ty se vsestranneji zdokonalujes, mene lidi ti keca do prace nebo se v ni vrta, apod... Ale muze to mit jednu nevyhodu - autorova slepota. Pokud mas na dane feature dostatek casu, nemusi to byt problem. Obecne ale jednoho cloveka nenapadnou vsechny kombince (a ze jich obcas muze byt... ;) ).

Kdyz pises, ze delas "TS writing (+review)", myslis tim review urcite delat na TS nekoho jineho, ale patri do toho i studium analyzy, nebo je to spis review konvenci (konvence nemusi byt pouze o kontrolach syntaxe, existence vsech povinnych informaci, etc... , mohou obsahovat i pravidla primo vymezujici povinne/automaticke kroky zamestnance v dane roli, nebylo by tedy mozne upresneni :) )?

Na zaklade Tveho popisu bych videl jako nejvetsi hrozbu Tvuj cas. V moment, kdy manageri zjisti, ze se stavajicimi odhady na casovou narocnost testovani produkuje firma bezproblemovy (dle reakci od klientu dostatecne kvaitni) sotware, zacnou snizovat odhady na potrebny cas, aby tim usetrili. V pripade, ze je to ucineno dostatecne pomalu ( a da se tomu jeste pomoci rozumnymi argumenty ), pak v moment, kdy si vsimnes ty, ze ti nejak nestaci cas a makas vic nez pred pul rokem, muze byt pozde. Pokud mas na starosti celou featuru, ani si neuvedomis, ze te nenapadne neco, co bys pred tim pul rokem rozhodne nevypustil. Zkratka, pokud ty, jakozto clovek, ktery zodpovida pro danou oblast za vsechno, nebudes mit skutecne dostatek casu, ktery bys mohl profesne a kvalitne vyuzit, muzes zacit delat chyby na ktere "se prijde az pozde"?

Unit testy: Trochu otazka, kdo je ma psat? Analytik, designer, architekt, vyvojar... Vsichni premysli primarne nad tim "Jak to ma fungovat a co to ma delat", jak tedy maji psat scenare, kterymi maji hledat chyby? (snazit se zborit aplikaci kterou sami pomahali stvorit? Je skutecne malo vyvojaru, kteri by sve ditko takto doslova trapili...) Ovsem, pokud berete unit-testy jako neco, co ma pouze prokazat funkcnost komponenty/unity v analytikem definovanych stavech, pak s tim nemam problem. Rozhodne bych ale nesouhlasil s tim, aby tester/{QA analytik} na unit-testech vyvojare stavel svoje vlastni TS. ( Nebo jako metodik "bych si nad tim dovolil nesohlasit" ROFL )

AMBERAN:

1. Tak s tim souhlasim. v zavislosti na velikosti projektu rozhodnout, kdo a kolik lidi bude co delat. Vcetne toho, aby byli testeri/{QA analytici povinne ;)} zarazeni do jineho oddeleni, tj. aby se zodpovidali jinemu vedoucimu, nez vsichni ostatni vyvojari, idealne by meli byt "o uroven vys", aby jejich slovo melo patricnou vahu a testeri zodpovednost...

2. Podle velikosti projektu a podle velikosti lidi? :)
3. Whitebox testy provadeji vyvojari, kteri pisou unit-testy? Takze white-box testy se primarne pouzivaji pro "funkcni testy" a prisou je sami vyvojari? Vyvijite sw podle Test Driven Development?
4. Jasne, na tom se s OASHI zrejme shodnete... :)

PS2ALL: Podivejte se v kolik to pisu, necekejte ode me zadne prilis inteligentni reakce a pravopisne chyby prechazejte s nadhledem testerum vlastnim...
thx :-D

Zdrojaky rozhodne nestuduju! :)

RUPIUS:
1) Podle velikosti projektu, ale testeri jsou vzdy zvlast (ve skutecnosti jsou u nas oddeleni v jinem oddeleni a pridelovani na projekt). Nekdy jeden clovek zastane praci test analytika i testera, jindy je to oddelene...
2) Podle velikosti projektu, jsou lidi, kteri delaji na jednom projektu, jsou lidi, kteri maji projektu vice.
3) White-box je vetsinou zahrnute do unit testu, tedy provadeno vyvojari. Testeri delaji hlavne blackbox, nekdy trochu greybox, pokud tomu odpovida testovany software a hodi se to.
4) Podle velikosti a trvani projektu, nekdy oddelene, jindy to cele udela jeden clovek.

No a jak to funguje jinde??

Klienty nase logovani nezajima, to si delame my sami, ale take podle odsouhlasene specifikace: To je prave ten rozdil mazi FS a Designem.

Nase sablona na testscripty uz v sobe obsahuje kapitoly: "to pass", "to fail", "boundary", "hostile". A take priznak "is for regression y/n", takze nektere scenare (hc) se vlastne projdounanejvys 1x.

Na zacatku obdobi (cca 4 mesice) dostanem pridelene featury a o ty se "starame": QA time estimates, TS writing (+review), feature walkthru s developerem, pak testing ve VBL (pak developri maji commit/integraci do mainu), feature test na mainu + integracni test s jinymi novymi features, regresni testy a pak konecne walkthry s obchodnikama, predavacka (To uz teoreticky maji byt hotove releasenotes, ale ty si asi pisi v US sami). A proc to pisu: Nase norma na utilizaci je 80% (zbytek treniky, obecne firemni administrativa). Slovo ASAP u nas nema moc vyznam: Bylo by znamkou, ze meni plan, tedy znamkou chaosu, ale u nas je to vsechno tezce processni... tovarna s bezicim pasem.
...Ja ted mam na 4 mesice treba 5 malinkych featurek, ale i tak je to jen tak tak: Jeste se do toho prekryvaji predesly a prichozi cyklus, tak treba zaroven bezi integrace jednoho a estimates na dalsi.

RUPIUS: white/black boxy: Jasne, ze uz celkem vidim dovnitr (gray) a ze bych ten scenar mohl trekovat na urovni mezivysledku, ale pri "test to pass" je predpoklad, ze kdyz uz jsme na konci dostali spravny vysledek, ze se temi mezikroky nema cenu zabyvat.

Ovsem ty dilci way-pointy rozhodne maji svuj vyznam: Typicky jde o vnitrni interfaces, prechody mezi moduly a technologiemi. Takze treba "ulozeni mezivysledku do DB" je skvely "test to fail" scenar "...aneb mam napad, co zkusit, ze by se to tam treba nedostalo..." (a to oficialnimi akcemi z aplikace, zadne hacky) A tim se tedy ty mezivysledky pak podrobne pretestuji. ...ale idealne jen 1x na konci dev procesu. Anebo jako napoveda pri identifikaci testu.

A pak jeste mame boundaryhostile testing, kdy se ten interface vyslovene sleduje, a cilene se delaji takove akce, aby to opravdu selhalo... A to vcetne hackovani za behu, podvrhovani spatnych vstupu jako-ze-z-predesleho-modulu: Tim se treba testuji chybaova hlaseni. Totiz i logovani je (muze byt) predmetem testovani, protoze to pak zase usetri spoustu casu pri kazdodennim supportu (a tudiz i penez klienta a jeho live businessu). Ale to uz je spis ad-hoc testing: Sice se nektere svcenare i mohou zahrnout do testscriptu, ale... ;) A tohle uz se opravdu dela na samy zaver feature/enhancement developmentu, driv to nema cenu: jeste se ten kod prilis meni.

...tedy u nas. ;)

AMBERAN: Jasne, ale kdyz se zamyslis, jde o to, zda je ta testova dokumentace k necemu dobra. Prvni krok je OK, tj. je vytvorena podle pozadavku zadavatele/uzivatelu/klienta , ale otaznikem zustava, zda je testova dokumentace dostatecne dusledna, pokryva potrebny rozsah aplikace a zabyva se nejen pozadovanymi procesy, ale i temi, ktere "proste mohou nastat"?
ANEB,
je strasne jednoduchy napsat testovou dokumentaci tak, aby vyhovovala aplikaci, ale protoze jsme lidi, podvedome k tomu inklinujeme, ikdyz vime nebo alespon tusime, ze to tak neni spravne... :-)

Koneckoncu proto existuje metodika, aby stanovila procesy, kterymi se bude snazit eliminovat lidsky faktor. (Ovsem legrace nastava, kdyz se metodik zamysli nad tim, jak eliminovat lidsky faktor svuj vlastni! LOL To vetsinou zkonci u piva ;) )

Mam na vas par {dotazu}/{temat do diskuse}: -)
1. Kolik Vas testuje jeden projekt a jake jine prace pri vyvoji daneho sw jeste zastavate?
2. Pracujete vzdy vyhradne na jednom projektu, nebo se u Vas stane, ze jich Vam lezi na stole rozpracovanych vic?
3. Pouzivate i white-box testovani?
4. Jak mate rozdelene psani testove dokumentace/scenaru a vlastni provadeni black-box / white-box testu mezi jednotlive testery?

OASHI: Ve chvili, kdy software vyhovuje testovaci dokumentaci, vytvorene podle vyvojari rozvinutych uzivatelskych pozadavku :-)

OASHI: Tak to mas pravdu, ale dulezite voditko podle me je, zda se pri provadenych testech objevily prvni chyby na opravu. Pokud ano a pri druhych uz se chyby nenasly, je to lepsi, nez kdyby se nenasly vubec zadne. To pak clovek nevi, kde se co teprve zvrzne, neda mu to spat a premysli, co zapomel otestovat a overit. :)

OASHI:
tak mas nejaky soubor testu (programatorske, uzivatelske, ...) a kdyz ti vsechny projdou tak to je "hotove" (neni to to same jako bezchybne ;-) )

Pri overovani, "ze tam uz nejsou chyby", kdy se zastavite?
...chyby tam totiz stejne jsou, jen jde o to, je najit... ;)

OASHI: Delam ve treti firme, to ano, ale ne ve vsech to bylo zrovna QA a navic ho v te treti minim teprve zavadet... ;) No, nebude to vubec jednoduchy...

RUPIUS: No, rikal jsi, ze uz delas QA ve treti firme, tak to uz mas nadhled. Ja to delam 2 roky stale v te jedine...

...hm, to je na dejsi koukani, nez ted honem...
Diky!

Jen tak pro lidi co zajima ISTQB, tady je Syllabus, coz je prakticky ucebnice z ktere se to uci a je v cestine, takze nerusim, za nektere prereky, ale zatim jsem na nic nenarazil, takze kdo by mel zajem, at si pocte neco teorie :)



ISTQB_CTFL_Syllabus_v2007-CZ-beta1.pdf (474714 B)

OASHI: LOL Pokud ja jsem odbornik, je jim kazdy, kdo se snazi pouzivat mozek a svuj rozum. Takze jsme na tom ja, ty a MICTECH asi tak nastejno, ne? ;)

RUPIUS: Slovo odbornika. Dekuji a poklona. :)

OASHI: Netusim, "jak se to ma delat, kdyz se zacina" a neznam zadne oficialni, univerzalni a vseresici postupy (ani nikoho, kdo je zna), ale jsem osobne presvedceny o tom, ze slepe dodrzovani jakekoliv metodiky neni tou nejlepsi cestou.
Co firma, to original. Me soucasne zamestnani je mym 3 setkanim s QA nebo alespon testovanim a vzdycky to bylo jine. Potreby jsou jine, priority jsou jine, lidi jsou ruzni...

Mam za to, ze firma ktera uzna, ze potrebuje metodika, ktery bude sjednocovat praci na projektech, aby si lide rozumeli a zbytecne si nelezli do zeli, a aby "to hezky slapalo", potrebuje cloveka, ktery se o tu metodiku bude starat, hledat jeji slabiny a vylepsovat ji.

Vsude, kde "se uz neco dela", dela se to podle stanovene metodiky nebo alespon nejakeho domluveneho postupu (coz je vlastne pouze pisemne nevydana metodika :) ). Nebyl jsem a aktivne se nepodilim na vyvijeni/nasazovani metodiky uplne od nuly, ale vzdy uz existovaly nejake vice ci mene domluvene definovane a funkcni rocesy. Na vsech realnych projektech je mozne si vsimnout nedostatku a komplikaci, ktere by bylo dobre optimalizovat, aby nezabiraly tolik casu, vystupy obsahovaly mensi mnozstvi chyb, informace byly pokud mozno uplne jednoznacne...

Kdyz se zacina, urcite neni spatne projit si par znamych metodickych postupu a analyzovat si v cem jsou jejich vyhody, nicmene pachani merge ruznych metodik, pokud by to bylo vubec mozne ;), bych se radsi vyhnul... :)