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ě)