Tento web používá soubory cookie. Dalším používáním webu s tímto souhlasíte.
jméno
heslo
přihlásit
zaregistrujte se
zapomněli jste heslo?
QA - Quality Analysts / Assurance - kvalita SW - testování, testeři - Každý ví, kdo je programátor, ale kdo zná QA? :'(
OASHI
QA: Quality Analysts / Quality Assurance / Quality Engineers

Developeři nás milují! ;) A my je také. :)
Každý ví, kdo je programátor, ale kdo ví, co je QA? :'(

Děláte to? Provozujete QA?
Testujete? Píšete si test scripty?
Máte snad automatizované smoke testy? (pozor, neplést s unit testy, ty nechme developerům, ať si ty své chaosy debugují sami... ;)
Už ať jste tu!

Hlášky:
* náš šéf QA oddělení: "I am just a junior tester..."
* náš šéf QA oddělení: "I dokumentace je předmětem testování!" ...bohužel se o tom přesvědčuji až příliš často, ty FuncŠpeky bývají dost odbyté...

Témata:
Procesní organizace - http://en.wikipedia.org/wiki/Process_management
RUP - http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process
Total Quality Management - http://en.wikipedia.org/wiki/TQM
Critical Chain Project Management
Test Driven Development
Máte k tomu co říct? Vložte se do diskuze.
MINER --- 18:22:34 23.9.2008
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ě)
RUPIUS --- 1:15:12 23.9.2008
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
OASHI --- 1:01:32 20.9.2008
Zdrojaky rozhodne nestuduju! :)
AMBERAN --- 13:06:43 19.9.2008
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.
OASHI --- 22:50:28 18.9.2008
No a jak to funguje jinde??
OASHI --- 22:50:12 18.9.2008
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.
OASHI --- 22:37:45 18.9.2008
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. ;)
RUPIUS --- 20:43:03 18.9.2008
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?
AMBERAN --- 17:29:39 12.9.2008
OASHI: Ve chvili, kdy software vyhovuje testovaci dokumentaci, vytvorene podle vyvojari rozvinutych uzivatelskych pozadavku :-)
RUPIUS --- 12:00:38 12.9.2008
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. :)