• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    OASHIQA - Quality Analysts / Assurance - kvalita SW - testování, testeři - Každý ví, kdo je programátor, ale kdo zná QA? :'(
    OASHI
    OASHI --- ---
    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?
    RUPIUS
    RUPIUS --- ---
    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?
    OASHI
    OASHI --- ---
    MICTECH: Ale aspon mas "waypointy".
    MICTECH
    MICTECH --- ---
    KOC256: myslim, ze tu metodiku poprve budes muset delat za behu, protoze nazacatku naprosto netusis jak se to bude chovat v praxi :)
    OASHI
    OASHI --- ---
    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...
    KOC256
    KOC256 --- ---
    MICTECH:
    nemusi pokud to dela nekdo kdo tomu rozumi... ale musis predem vedet kterym smerem se chces dat (mit hotovou tuto metodiku a nedelat ji behem projektu)
    MICTECH
    MICTECH --- ---
    KOC256: moc dobre te nachapu, tak kdyz si vemu z kazdyho neco a udelam si svoji agilni metodiku, tak to pak vyznamu nepozbyva
    KOC256
    KOC256 --- ---
    MICTECH:
    ano pokud zase nejaky celek ucelis tak OK. ale pokud ted si reknes to udelame podle RUP, pak neco podle SCRUMu a nakonec neco podle XYZ tak pak jednotlive CELE promyslene metodiky pozbyvaji vyznamu ne?
    MICTECH
    MICTECH --- ---
    KOC256: to prave ne

    clovek si ma tu metodiku upravit podle svyho, pripadne vzit z vice metodik to co mu nejvic vyhovuje a defakto si udelat vlastni metodiku
    LOBOTECH
    LOBOTECH --- ---
    KOC256: No chyba je naopak v tom, ze metodiku dodrzujou do posledniho pismene :o) A tak to proste nejde :) Mas tu faktory jako smrtici terminy od zakaznika, nepristupnost lidi, nevyhovujici test podminky atd atd :) No a nemuzes proste rict "My vam na to dlabem pane chlebodarce, pac tu mate desnej bordel a dokud nebude po nasem, tak smulicka" :) To by se firma moc neuzivila :) Dycky je potreba najit kompromis, ale existujou proste body v kterejch se ustupovat nevyplati, protoze kdyz to udelas, napachas vetsi skody, nez kdyz o ten projekt prijdes :o)
    KOC256
    KOC256 --- ---
    LOBOTECH:
    a neni prave chyba ze se "zneuzivaji" jen casti metodik a nakonec z toho vznika prave chaos?

    Bud snad metodiku drzim a nebo ji nedrzim...

    Ale samozrejme vim ze i tak se da fungovat...
    LOBOTECH
    LOBOTECH --- ---
    No vono je hlavni, aby se clovek neridil tupe metodikou, ale vybral si z tech metodik to co prave potrebuje aplikovat na svuj projekt a tim si maximalne zjednopdusil praci a predesel problemum, jak produktu, tak svym vlastnim :)

    Treba jsem delal pres rok a pul ve vodafonu bodyshopove a tam maj metodiku "JEDEN VELKEJ CHAOS!" a taky fungujou :D Sice lepej zaplatu na zaplaty, ale porad fungujou a prosperujou ze jo? :D
    OASHI
    OASHI --- ---
    Ale zase, z te spiraly by se dalo u prilis castych zmen dale i zanedbat spoustu dokumentace (nezto probehne koleckem, tak uz to mam 10x nabuseny),
    takze to vlastne sklouzne k extremnimu programovani ala prototyp,
    a uz jsme u toho Vondrakova odtrasujiciho prikladu...

    Nebo kde jsem si tu ve sve uvaze az prilis zkratil cestu? ;)
    OASHI
    OASHI --- ---
    A to se tyka pokazde nejakeho jineho produktu?
    U nas se totiz jedna stale o jeden "projedkt" ;) Tedy POSka, obrovska vec, ke ktere se lepi enhancementy dle pozadavku klientu. Tech mame backlog na dalsi dva releasy.
    Treba Tebou zminovane verzovani se u nas dela uz automaticky, to se resit uz nemusi. Co se naopak resi velmi (ale vyyysoko nade mnou) je naplanovani jednotlivych featur do nadchazejiciho releasu (skupina TLT - Technological Leadership Team). Na tom se ale vyradi hlavne nasi Starsi spolu s Clientskymi Managery (stycni dustojnici s klienty). Ti s klienty vykomunikuji "hruby odhad nakladu", za podrobnejsi odhad uz klient plati. (!)
    Pak nekdo z tech zasvecenych napise FS, klient ho podepise a od te doby je to svata relikvie, na kterou uz se nesaha. A pokud chce klient zmenu, padne nejspis az do pristiho releasu jako "enhancement na enhancement".
    ...a mezitim, co my delame "QA time estimates", developeri si pisi interni Designy.
    A jak je to jednou napsane (a po review, to ma kazdy dokument, cca 1 hodinu beseda po telefonu), uz je to opet vlastne nemenitelne.

    Pak se to vyvivji ve feature branchi (feature test to pass), 1-2 recycles, pak commit do mainu, opet test (to fail, boudary & hostile) a zaroven i integracni test (ze se to nepere s jinymi featurami) + nasledna verifikace fixnutych defektu.

    Na konci releasu, kdyz jsou vsechny featury hotove, se udela regrese (ze novinky nerozbily nic stareho, drive funkcniho + recycle na fix defektu). Pak QA predvadi featury Klientakum. Nevim, kdo pise Release notes, to si asi v US delaji sami.

    Jak vidite, u nas je to opravdu waterfall, zadna spirala. To u vas, koukam, je to spirale docela i blizko...
    LOBOTECH
    LOBOTECH --- ---
    No u nas to funguje, nebo by melo fungovat tak, ze pokud sem na projektu a rucim za vse, tak to zacina dohadovanim se a vyjasnenim si cilu testu, aby klient vedel co vlastne po me chce :) (a to i ve firme), kdyz se dohodnou cile, schanej se requirements a dohaduje se o requirements aby v testech pak nebyl bordel.
    A kdyz mas requirements, tak si vypracuje clovek dokument o cilech testu, rizik testu, prostredim, iteracich, verzovani, podminkach nasazeni noveho buildu atd atd atd.
    No a nez clovek zacne delat Test Cases jako takove, tak se zase dohaduje o tom co je potreba, co se musi udelat, kolik je na to casu, kolik lidi atp.
    Hmno, pak se udelaj test cases, obcas i test scripts pokud je to vhodne.
    Pak se testuje a testuje a testuje a opravuje a opravuje a honej se terminy a ve finale kdyz je produkt ve slusnym stavu, se vyjedou nejaky statistiky, grafy atp (coz se ostatne dela i behem testu aby projektak vedel jak na tom je) a napise se vyhodnoceni testu z kteryho je jasne vidno,co bylo a co nebylo otestovano, statistika ze strany test cases, dale osobni nazor na produkt, navrhy na vylepseni (to samozrejme probiha i behem iteraci), zmeny oproti puvodnim pozadavkum atp :o)
    A pak se produkt preda zakaznikovi, ten si udela akceptacni testy (ktery obcas delame my, pac uz mame v tomhle dobry jmeno, takze nam verej) a pak uz se jen jede chlastat za dobre vykonanou praci :) A pak prijde zakaznik zas s necim novym uzasnym a cele to zacina na novo :D Samozrejme ze na zacatku predemnou je este analytik, kterej s tim ma desne prace, pac dobra analyza je proste zaklad :)
    OASHI
    OASHI --- ---
    No, a jak to funguje u vas?
    Dokumentace (delate zpetne updaty na postizeni skutecne aktualniho stavu?),
    testovani (integracni + systemove, jak pise Vondrak&RUP) ?
    OASHI
    OASHI --- ---
    Hm, tak jsem si ten RUP rychle nacetl...
    Vlastne podle toho jedem. S jedinou vyjimkou te vizualizace, neb to nemame v UML.

    Ty recycles, ze jsem 2 zazil jen jednou, tim jsem nemyslel iterace, ale vraceni uz "hotove" veci zpet pred development, kdy se zacao +- znovu prespecifikovanim pozadavku. ...prvni pokus se tak dal brat jako "prototyp", kdyby ovsem vsichni puvodne nedoufali, ze to bude final. ;)
    Ano, selhalo to na nedostatecnych pozadavcich. Nebo spis, pozadavek byl jen mrnavy, ale s dalekosahlymi vnitrnimi dusledky do toho naseho reseni, na ktere klient pozadoval enhancement.

    Diky za link, urcite se hodi: Do tedka jsem UML videl jen teoreticky, tohle konecne zavani praktictejsi metodikou skutecneho pouziti. (ikdyz ocekavane UML znazorneni casovych navaznosti ala Gannt tam take nevidim :) Ale to jeste musim nastudovat podrobne.
    Opravdu se tu dotedka obejdem bez UML... Veskere dokumentace: Business requesty, funcSpecs, code-designy, tim eestimates, testscripty, release notes, user docs... Vse bez UML!
    KOC256
    KOC256 --- ---
    OASHI:
    1/ nas na skole jiz pres X lety ucili ze metodika waterfall je zastarala...
    2/ http://www.cs.vsb.cz/vondrak/download.html

    je tam vice nez malo peknych veci...
    doporucuji: Uvod_do_softwaroveho_inzenyrstvi.pdf
    OASHI
    OASHI --- ---
    KOC256, LOBOTECH: Hmm, no jeste jsem toto nevidel, ale koukam, ze vlastne postupojeme podle neceho dost podobneho. Vytvorili jsme si vlastni takove procesy, tesne napojene na nas vlastni "bugtracker". Management ma vubec snahu delat veci "processne". Ale po te hromade akvizit po celem svete stejne jedna divize nevi, co/jak se dela ve druhe. Vlastne i dve odeleni v jedne divizi si to kazda vede posvem, pritom je to oficialne jediny produkt...
    ...no, nektere veci moc nefunguji, treba navrat ve waterfallu o vice jak jeden krok jsem zazil snad jen jednou a to bylo za srdceryvneho upeni, ze "na to neni process!" :)
    Ale celkove se nam, myslim, TQM docela dari: Diky QA pochopitelne! ;)
    Diky za link!
    LOBOTECH
    LOBOTECH --- ---
    OASHI: Ups :) To je metodika testovani (nejen testovani, je to vyvoj softwaru celkove). Sice nesouhlasim se vsim co je tam psano, ani se mi nelibi vsechny jejich sablony, ale je to takova bible testovani a kdyz se to naucis poradne, nebudes mit se schanenim prace imho problem :)
    Na wikine mas strucnej popis
    http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process
    Kliknutím sem můžete změnit nastavení reklam