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... :)

RUPIUS: Mohu to tedy brat tak, ze z metodiky (popisujici standarni situace) se uhybat nesmi a mela by se naplnit,
ale na druhou stranu, ze metodika neni primo postup, jako spis ramcove smerovani, ke kteremu (...k realne provadene cinnosti) se da jeste cokoli dalsiho pripojit (reseni nestandizovanych pripadu), a obzvlas do budoucna to treba i do ni zahrnout, ji rozsirit.... Ano?

To me ale pak navadi k tomu, abych ty zakladni obecne zname metodiky uz rovnou mergnul do sebe a az vysledek vzal za svuj startovaci bod... Tak se to ma udelat, kdyz se zacina?

Pratele z QA&T,
procetl jsem si tuto diskusi a dovolim si pridat svou prvni trosku do mlyna.
Z jakekoliv metodiky je mozne udelat chaos prave tim, ze se nedodrzi, ale ridit se slepe pokyny sepsane "nejakym blaznem" postrada puvab a zpusobuje ztratu zpetne odezvy.
Metodik by mel vedet, jak se jeho metodice dari v tvrde zivotni realite sw vyvoje. Jen tak muze rozhodovat v problematickych pripadech, ve kterych se standardne "metodika obejde". On je ten, ktery ma domyslet mozne dusledky a predchazet pricinam komplikaci a problemu.
Metodika se vyviji spolecne s firmou, projekty i lidmi ve firme, jejich profesionalitou i charakterem. Zni tomozna jako snuska propagandistickych kydu nejmenovanych firem snazicich se prodat sve metodicke a QA profesionaly, ale ja jakozto metodik QA&T na tyhle veci skutecne myslim, resp. se o to alespon snazim. ;)
Kazda z metodik ma sve slabe stranky a kazda metodika musi zit, musi o ni byt pecovano. Metodik/a je pro lidi, nikoliv lidi pro metodiku/a.
Jak je to u Vas s metodikem pro QA&T?

MICTECH: Ale aspon mas "waypointy".

KOC256: myslim, ze tu metodiku poprve budes muset delat za behu, protoze nazacatku naprosto netusis jak se to bude chovat v praxi :)

LOBOTECH: Mne to take tak prijde, ze
1) Kdyz uz se zacalo podle jedne metodiky, tak se ji drzet, a nemenit ji za pochodu, protoze pak vlastne neni splnena ani jedna.
...chapu ale i druhy extrem je treba ucetnictvi Siemensu, ktere musi splnovat standardy CR, Nemecka i EU... A to vsechno najednou! Fakt extrem, kde neni prostor uhnout a clovek je tam jako "delnik v tovarne u pasu" nebo "zrnicko v mlynici".
2) A ikdyz se ta metodika splnili cela v jednom projektu, i v dalsim projektu by se mela pouzivat ta sama: Aby se dalo vyuzit zkusenosti posbiranych z predesleho, "learning by doing".

3) Ale: Nakonec stejne prijde sef a zarizne mi to: "chyby tam jsou, o nekterych vime, o nekterych ne. I klient o nich vi, ale umi s nimi zit! Takze uplatinime manazerske 80% vysledku za 20% casu a pustime to ven". Po tehle obvykle prupovidce sice musim priznat, ze "uz to staci", ale stejne uvnitr penim, protoze bych se na tom stale jeste vyradil... ;-] :( Ach ta realita...