TOWER: Pres ty co u nas jediny zatim delaj zkousky v cestine :) Nevim presne jmeno :)

Druhej level muzes mit bez prvniho? To ani nevim ze jde cece :)

LOBOTECH: pres Roberta D. nebo zvenku...?

Muhaha, konecne mam certifikat z ISTQB :) Sice jen foundation level, ale lepsi nez dratem do oka :)
Vy se chystate , nebo uz mate certifikaty?

OASHI: To asi maloktery tester, takze nejsi sam ;)

...takove to manazerske 20/80 ;) Ikdyz ja tu poucku moc nemusim...

OTAVA: U nas se nesmokuje zdaleka vsechno, ale prave jen ty nejdulezitejsi a davno vyresene kousky, rutinni pro QA, takze je uz ani nikdo nechce delat rucne, nemluve uz o "slepote"... Automatizovany je jen zlomecek, zato ten nutny.

OASHI: U nas smore test aplikace zajistuje DEV - ono to dava smysl pac proc projizdet nektery testy dvakrrat a potom je to jejich zodpovednost ze dodaji funkcni build.

Nedelame neco jinyho, taky jedem v inkrementalnim projektu, ale kdyz v kazdym buildu 1/10 - 1/5 objektu QTP nerozpozna a vyhodi chybu i kdyz je vsechno v pohode tak to snad ani nema cenu do toho investovat cas a usili :(

JVMLOK: Diky. ;)

OTAVA: No, u nas se dela stale na jedinem produktu, ktery neustale roste. Tim padem sice automatizace ma jakousi nadeji, ale zatim jde spise o hrube overovani buildu, ze neni "uplne nefunkcni".
...a i proto jsem zminil tu myslenku OASHI, ze je nutna znalost produktu... tolik jeste k JVMLOK.

OTAVA: Jestli delate pokazde neco jineho, to musi byt ale sakra narocne, to QA ukocirovat! 8-o

OASHI: podle wiki SQA jako Software Quallity Assurance

OASHI: Zkouseli jsem u nas Quick Test Pro, ale bohuzel programatori nebyli schopni udrzet disciplinu a kazdy objekt byl pokazdy jiny takze ve finale skripty uplne k nicemu, coz si myslim ze je obecny problem dneska - takze dokud nezacnou programatori programovat s ohledem na budouci QA tak je automatizace k nicemu.

JVMLOK: "tým 10 QA pro vývoj v JAVA/J2EE"
Jsem mel za to, ze QA je na technologii nezavisle. Vzdyt nam je jedno, v cem si to devs zbastli,ne?

Obavam se, ze programatori jsou preci jen snaze prenostitelni z projektu na projekt: u QA preci jen dost zalezi na znalosti samotneho produktu, ze? I jako sebelepsi QA, bez te apriorni znalosti o produktu se stejne musi zacit jako ono "PTO", az pak se zacnou rozsirovat obzory... U nas to bezne trva pul roku "dotovaneho provozu", to uz developeri "bušiči" firme vydelavaji. :(

Ad, automaticke testovani: To je vubec orisek: Bez toho, aby nam developeri zpristupnili nejake ty interfaces si neskrtnem. A i pak: Jakou automatizaci pouzivate?
U nas se zavedl Pyton, ale z toho tedy stastny nejsem... :-/

JVMLOK: SQA - co ta zkratka znamena, to "S" ?

Přátelé, oslovuju Vás takhle ploošně z několika důvodů. Je to trochu OT, můj obor není testování a SQA, ale personalistika. Co jsem vysledoval během posledních několika týdnů, je na českém trhu výrazný nedostatek alespoň trochu zkušených Testerů či QA Eng. Nevím čím je to způsobeno, možná je to proto, že každý v tomhle oboru pevně sedí na své židli a nepotřebuje změnu. Není problém najít partičku testerů do firmy, kde se jim říká PTO (PapírTužkaObrazovka) ale najít člověka který zná metodiku testování a je schopen pracovat i na vývoji testovacích scénářů a automatického je téměř nemožné. Pracuji v jihomoravském regionu a v současné době potřebuju dát dohromady tým 10 QA pro vývoj v JAVA/J2EE. Pokud někoho znáte a měl by zájem, dejte mu prosím vědět ať se mi ozve. Kromě toho, že jde o velmi prestižního zaměstnavatele a projekt, jde také o strategické pozice, jejichž obsazení rozhodne o tom, jestli další vývoj projektu, případně jak velká část vývoje bude probíhat v ČR nebo někde jinde ve světě. Ještě jednou sorry za OT a dík za pochopení.

...ne e: I ta feature branch ma regulerni kompleti build proces.
Ja si to musim cele instalovat a rozchodit, testuju stejne, jako na mainu / newdevu / hlavni branchi...

Jedem .NET a to tvoje mi trosku zavani whitebox testingem, fuj fuj ! :)

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.