Ale ano, projekty jedou, zakazky take jsou (info potizich by fakt nepustili, ale zakaznici nektere upgrady skutecne stopli), praci mame nasmlouvanou minimalne na par mesicu dopredu...

Mel jsem spis na mysli, ze i pri drivejsim prinedostatku lidskych zdroju zavedli restriktivni opatreni: treba skoleni, bonusy, HR benefity, pravidelne pulrocni parties s rodinami padly...

Jen jestli se jim ta soucasna situce nehodi do kramu jakozto prima vymluva! Uz se desim, co si na nas vymysli pri nadchazejicich kazdorocnich jednanich o zvysovani platu... Vyhazovani se konat nebude, toho se nebojim, ale stale zustava spousta moznosti, jak nas nepotesit...

U nas se maka, projekty jedou a vsichni manazeri se snazi stahnout naklady jako vzdy a jak je to mozne. Nerikam, ze na nas svetova krize nema vliv, ale nezda se mi to, alespon zatim, nijak dramaticky. Naopak, dalsi projekty se chystaji a planuji, na metodikach, nejen tech testovacich, se pracuje... :)
Zkratka, nevsiml jsem si ani nezaslechl nic o tom, ze "by se neco stornovalo, zrusilo nebo ukoncilo kvuli svetove krizi".

No nevim jak u vas, ale u nas snad uz ani dalsi bugy nema smysl hledat: Ze skaly 1-5 (5=critical) se ted pacuje na 4 a vyse, na nizsi nejak nejsou zdroje. Delevoperi jsou vecne pretizeni (nebo spis je vytizena kapacita, planovani funguje). A to mame ted stop stav...
Koukam, ze jestli se honem rychle neponorim do dotNetu, ze asi budu ohrozeny druh. :(

Mno ve velkych firmach to ted chodi tak, ze se zaviraji projekty, ktere nejsou zivotne dulezite. A protoze se takto setri, tak se stabilizuje to, na co nebyl pri vseobecnem spechu cas, coz paradoxne pritahuje zvysenou potrebu testeru/metodiku, ale musi si testeri zvyknout, ze nedostanou ani zlamanou gresli na takoveto velke testovani ... Takze kdo optimalizoval a ma metodicky pokryto, tak zvladne dotahnout v ramci testovani mnohe. Ostatni budou naopak vice odkryti HR sniperum a mohou mit smulu...

OASHI: z naseho tymu sli 2 lidi a ja sem jednim z nich :) od noveho roku hledam praci jinde :) Ale sli lidi ze vsech oddeleni, nejen z naseho a dostal sem moc pekne odstupne, takze si zas tak nestezuju :)

OASHI: hele, nemaluj certa na zed, ja ted nechci prijit o praci.. Kdo propousti testery?

Jako by mela svetova krize vliv i na QA...
Zda se mi to, nebo jsme pri propousteni prvni na rade!? &-(

OASHI: jeste k diskusi na verejnych forech od Adv. level ISTQB, chlapik Ind se tam ptal, jak se ma pripravit na AL, kdyz jsou tezko dostupne materialy, hlavni guru mu odpovedel:
There are a number of pointers to books in chapter 11.2 of the ISTQB AL syllabus version 2007. You can also look at the different standards mentioned in section 11.1.
That, plus the references present in the Foundation level syllabus should be a first step to self training.

However you should be aware that the AL certification is very difficult and open only to experienced testers with a number of years testing experience.

Best regards
B. Homès, Edito & Author ISTQB Advanced Level syllabus

OK, diky! ...na nastence.

http://www.stest.com nebo http://castb.org

Jsem zadny jejich web nenasel... Nejaky kontakt?

LOBOTECH: STEST, s.r.o., vim...

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: chtel bych jit venku rovnou na 2nd level.... pokud to cas a finance dovoli...

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