• ú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? :'(
    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
    rozbalit záhlaví
    FONTAIN
    FONTAIN --- ---
    OTAVA: to podepisování je super nápad! Díky moc.


    N0NECZ: je to protože si na developery nikdo nedovolí?
    Naštěstí celej team ví kde je chyba, a že je u nich. My jsme přeci taky lidi. Jasný napadne mě 5 UC , ale rijde někdo jinej a napadne ho 6tej. Smutný je, že najdeš 30 chyb, ale nevšimneš si tři hovadin a už seš špatnej testr.

    OTAVA
    OTAVA --- ---
    FONTAIN: normalne, napises si enjaky actory, nahazis tam usecasy, popises UI a nechas to enkoho podepsat a pak testujes tak aby to odpovidalo. Kdysi jsem psal par requirementu a lisi se to jak kde. Obecne si napises nejaou funkcni kostru a pak an to prihazujes veci podle nejakejch pozadavku nebo co ti prijde mailem. Cas od casu posles novou verzi an vedomi vsem kdo jsou v tom zainteresovany a kdyz bude nekdo proskat - tady jsem to pred mesicem poslal, nikdo neprotestoval, delat to co je tam napsano, nazdar.
    I kdyz todle by mel delat BA, no ale tak jsou firmy kde i jeden tester je luxus.
    OTAVA
    OTAVA --- ---
    N0NECZ: Nevim, v ceske firme jsem jeste netestoval :-)

    ale obecne obcas je absence dokumentace docela problem. Musuis se pak hrabat v nejakych JIRAch nebo dolejzat za developerama aby ti rekli co to ma vlastne delat. Ale to uz je IMHO principialne uplne spatne, protoze se nedozvis co to ma delat, ale co si developer mysli ze to ma delat a to nemusi byt nutne to stejne.
    Nakonec ale prece musi byt nekdo kdo ty defekty odsouhlasuje ne ? TTen by mel vedet jak to ma spravne byt.
    Pripadne pokud je v teamu nejaky nestastnik ktery je tam dele, bude mit takovou tu historickou zkusenost.
    FONTAIN
    FONTAIN --- ---
    N0NECZ: Jasně souhlasím s tebou. Já mám skvělej team, kluci se fakt snaží a když se chodím ptám, tak mi vysvětlují. Když je to potřeba. Samozřejmě jde hromada věcí odvodit jen z názvu, ale jak jsou tu věci, které mají určité souvislosti s validacemi. A to jsou věci, kde musíš vědět postup, jinak si nahranej. Pracuji na dvou projektech s tím, že jeden se pokouším předat kolegyni. Důsledek toho, že začínající testr dostal dva projekty, které obsáhnou víc než jeden úvazek. Takže jsem to logicky nezvládala.
    S tím, který si nechávám jsou spojeny celkem velké finanční toky. Pracuji jak na frontendu tak i v seedu, je to síť validátorů a podmínek. Už je to tak rozrostlé, že sami kluci občas už ani neví a musí se koukat do kódu.

    Já tu dokumentaci beru s otevřenou náručí, protože pak až se na mě zase bude pan D chtít vylejvat zlost, obouchám mu dokument o hlavu. Bohužel se teď dělalo všechno na rychlo, protože zákazník spěchal, takže se tam nasekalo docela dost chyb a pan D si šel na mě vylejvat zlost den před nasazením na produkci, hláškou: "když to testr posvětí a půjde to na produkci, dojde k finančním ztrátám, tak budem žalovat testra." Celá firma je skvělá a postavila se za mě.

    Nicméně proto bude i ta dokumentace, jen jak s tím začínám a nemám nikoho kdo mi něco ukázal musím chodit klást často asi divné otázky sem. Ale tak zase si tu aspoň pokecáme:)

    Díky za vaše názory.
    N0NECZ
    N0NECZ --- ---
    FONTAIN: Imo dost záleží s jakým týmem děláš a co přesně po tobě chtějí. Moc jsem se o teorii nezajímal, takže názvosloví mi mnoho neříká. Ale zažil jsem buď testování typu - už je vše napsané, akorát to projeď - což bývá sice nejvděčnější, pokud se člověku nechce moc přemýšlet, ale bývá to největší nuda.
    Potom je samozřejmě druhá možnost, kdy opravdu máš napsat testy, z čehož vyplývá, že by měl člověk i tak nějak vědět, co to má dělat. Dokumentace je sice ideální, ale většinou to končí jenom u toho ideálu = něco, co za normálních podmínek nenastává. Potom je třeba řešit jak s tím tedy postupovat. Já třeba taky většinou dokumentaci nedostávám, ale není problém po pár konzultacích s příslušnýma lidma zjistit, co se od toho očekává a jak to teda má být správně. Případně rovnou navrhnout něco, co by mohlo být líp, pokud se to nezdá. Není to zrovna pravidlem, že to tak chodí, ale u nás to tak funguje a musím zaklepat, že i když to není v souladu s normálním postupem, je to asi to nejlepší, co jsem zatím zažil. Moc se neřeší papíry, sepisování a byrokracie, ale rychlejc se dojde k výsledku. Bohužel, to je spíš štěstí na lidi a firmu.
    Pokud zrovna tohle štěstí člověk nemá, tak se asi dohodnout, jak tedy k tomu dojít. U x věcí se dá odhadnout, co to vlastně má dělat - čistě logicky (pokud bereme třeba nějaký webový frontend, najde se tam kolikrát hodně věcí i bez toho, aniž by k tomu měl člověk zrovna podklady, protože mu hodně věcí tak nějak dojde nebo je přímo vidí).
    No a co se dá říct jiného, než že pokud člověk nemá materiály pro práci které potřebuje a nejde to jinak, tak poslední možnost je to začít řešit s někým, kdo má možnost, aby se to napravilo. A pokud to ten někdo odmítá, nebo není člověk vyslyšen, asi si hledat něco jiného, pokud chce opravdu pracovat a ne jenom sedět a čekat jak dlouho to vydrží, než se začne řešit lavina šitu, které bude muset čelit.

    Ono, bohužel je i normální praxe, že se testování odehrává jenom tak pro to, aby se mohlo říct, že to bylo testováno, aby se odškrtaly příslušné kolonky, schválilo se, co se schválit potřebuje, ale reálný výsledek od toho nikdo nečeká. I takových jsem pár zažil. Důležité je to pochopit, jak to asi je a jak to zrovna v oné firmě funguje. Pokud firma jede tímto způsobem, případně si někdo s někým vyřizuje účty srze takovou záležitost, záleží už na nátuře. Odejít s tím "tohle si dělejte beze mě", nebo "fajn, když se na to kašle, já se snažit taky nebudu, akorát mi prosím dejte plat a dokud to půjde, tak spolu tady možná vydržíme...a nebo si mezi tím najdu něco, kde o testování opravdu stojí a ne, že si na tom jenom hrajou".

    Těžko říct, jak to máte. To asi musíš posoudit sama a rozhodnout se dle sebe a svých preferencí. Každopádně, pokud je firma dobře fungující, není na to člověk nikdy sám a komunikace je základ. Pokud firma a komunikace v ní nefunguje, pak je otázka co je vlastně cílem firmy a v takových se ne vždy testuje, aby se vlastně něco otestovalo a opravilo. Obzvláště u nás v Čechách.

    Nejspíš jsem napsal něco, co hodně lidí tady a i ty víte, možná že naopak. Přiznám se, že mně kdyby před x lety tohle někdo řekl, když jsem teprve testovat začínal, asi bych si ušetřil nějaké ty nervy. Ale nebudeme si nic nalhávat, že to platí pro většinu oborů.
    FONTAIN
    FONTAIN --- ---
    Ptala jsem se právě proto, že mě nikdo žádné dokumenty nedá a já mám udělat výstupy. Tzn. v Jira vzít tasky pospojovat si je, pochopit co to má udělat, popsat, otestovat vc. usecasu a vyhodnotit.

    Z toho co tu vidím si myslim, že za ty prachy tam, začínám být krapet nas....a.
    OTAVA
    OTAVA --- ---
    Ciste teoreticky je idealni postup :

    BA napisi use casy / requirements document.
    Testing / QA projde ty dokumenty jestli neobsahuji chyby nebo nelogicnosti, po sign offu zacnou psat test casy a Dev vyvijet. Takze tady je vystup sign off zadani a pripravene testcasy.
    Dev doda kod, QA otestuje, hodi jim zpet na hlavu chyby, dev opravi a tak dokola dokud se neodsouhlasi ze verze software je OK, sign off. Vystup jsou protokoly testu, hlasene chyby.
    Nekde je jeste UAT - User Acceptance Testing, ale zazil jsem to zatim snad jenom na dvou projektech.
    Kde maji automatizaci, tak asi napisou na novej kod i nejaky automaticky testy. Vystup - testy behaji a hlasi chyby :-)

    V ramci post release aktivit by meli BA shromazdovat feedback uzivatelu a Dev opravovat post Prod chyby, QA jim to pretestuje. Tady je pak jedna dobra vec ktera se dela hodne malo - QA, Dev, BA by si meli cas od casu sednout, projit vsechny post produkcni chyby, udelat analyzu co bylo spatne, kde se stala chyba a proc se ta chyba neobevila driv a upravit proces tak aby se takova chyba priste nasla (pokud je to mozne a efetivni samozrejme). Nezamenovat s hledanim viniku prosim.

    VYGIDOR
    VYGIDOR --- ---
    FONTAIN: mozno nie celkom chapem, ale dovolim si tvrdit, ze majorita prace je vystup z testovania.
    nova funkcionalita - podla pouzitej metodologie (ci ich kadejakych kombinacii a mutacii) to je vsetko od analyzy requirementov, EPICov, use case-ov, ... cez spatnu vazbu na ne, spolupraca na ich zmene/improvementoch v trojuholniku "developer - business analytik - tester", ci v inej konstelacii, cez navrh test case-sov, validaciu ich scope-u, test data manazment, s tym suvisiaca tvorba suite-ov, cela samotna exekucia a jej nasledny reporting.

    bug fixing - komplet vsetko od najdenie problemu az po jeho uzavretie je vystup pre niekoho.
    DYNK
    DYNK --- ---
    FONTAIN: Use case a popis funkcionality ma sepsat business. To by mel byt spis podklad pro test, nez jeho vystup. Za vystup testovani povazuju vysledek/protokol testu.
    FONTAIN
    FONTAIN --- ---
    VYGIDOR: Jj tak to vím, jen jsem se s tímto termínem nesetkala.

    Hele děláte nějaké výstupy z testování? Jako, že spisujete use case a popisujete tu danou funkcionalitu?
    VYGIDOR
    VYGIDOR --- ---
    FONTAIN: ticket = incident / defect / bug / issue
    imho .)
    podla toho, aky defect management tool sa pouziva, sa stretnes s roznymi oznaceniami .)
    FONTAIN
    FONTAIN --- ---
    VIDOCQ: chtela bych napsat,ze si me uklidnil :) Mozna blba otazka,delam to jen chvili,ale tickety jsou presne co? u nas to moc pres PM nejde...respektive jde,ale vicemene to co a jak se bude delat dela UX a ten to pak rozporcuje do jednotlivych tasku s hlavnim developerem.
    VIDOCQ
    VIDOCQ --- ---
    FONTAIN: jo zadání se řešilo vždy a všude a pořád dokola. IMHO nejlepší způsob jak se takovým problém vyhnout je jednoduše říct, že když zadání není, tak ten ticket se dělat jednoduše nebude. Takhle to teď funguje v AB a je to asi nejlepší systém se kterým jsem se setkal. Projekťák a šéf business analytiků hlídají v jakém stavu je zadání. A dokud to neschválí, tak prostě nedostane ten ticket zelenou. Jako je jasné, že zadání se piluje ještě během vývoje ale je vždy na čem stavět.
    FONTAIN
    FONTAIN --- ---
    Otázka...píšete tu o zadání....já bohužel žádné zadání nedostávám, v postatě jedem jen issue v Jira a, když je description, která má hlavu a patu, tak to z toho pochoppím. Jinak z názvu max. A pak se to různě snažím najít a pochopit jak ten systém má vypadat.
    Jak tomuhle predejít a připravit se na to...jak to chodí u vás
    VIDOCQ
    VIDOCQ --- ---
    OTAVA: hele není tak tak špatný. Dělá vždy se dopředu a co se nestihne, to jde prostě do dalšího release. Ale pravdou je, že občas je v tom trochu guláš co má jít do jaké verze. Zadání testeři dostávají ve stejnou chvíli jako programátoři. A nasazovaní na prostředí si řídí taky testeři, takže se prostě testuje po kouskách vždy to co je hotové.
    SUPCZ
    SUPCZ --- ---
    Letos v novém dresu, ale stejně jako každý rok, sponzorujeme CzechTest. Zaujalo vás něco v programu (http://czechtest.com/programme) a chystáte se?
    OTAVA
    OTAVA --- ---
    DYNK: ty prvni dva tydny (nebo prvni tyden) se dodelavalo neco z minula, nejaky ty produkcni bugy a jinak veget. Ano, bylo to samozrejme vsechno spatne, taky jsem tam byl necely rok, nez jsem si rekl ze tohle nemam zapotrebi.
    DYNK
    DYNK --- ---
    OTAVA: tyjo a co jste delali ty prvni dva tydny? :) Ja, kdyz jsem jel na mesicni releasy, tak se testoval dalsi jeste pred nasazenim predchoziho. Ten model, kterej popisujes vypada bud na hodne malej tym, nebo na hodne spatnej management, pripadne kombinaci obojiho. Mne ty mesicni releasy docela vyhovovaly v tom nasem setupu.
    OTAVA
    OTAVA --- ---
    (tim netvrdim ze v AB je to stejne !)
    OTAVA
    OTAVA --- ---
    Aj, ja delal v rytmu mesicnich releasu a byl to voser. Developeri nam nedali kod tak prvnich 14 dnu, pak to behem tejdne vsechno prislo a my meli tak tyden, deset dni to otestovat, nahlasit bugy, retestovat a jit do produkce. Nevzpominam na to rad, kazdej release byl pruser, jenom se resilo jestli malej nebo velkej a jak dlouho trvala oprava produkcnich bugu.
    VIDOCQ
    VIDOCQ --- ---
    Čus, jestli hledáte práci, tak Air Bank zrovna nabírá testery do Prahy. Jeden na HPP druhý na IČO. Jde o manuál testování NF, jede se v menších týmech. Release každý měsíc. Bugy a ostatní tickety se evidují v JIRA. TC se píšou do Spira. Plusem jsou nějaké základní znalosti psaní TC, SQL(oracle) a umět si provolat webovou službu přes SOAP. Kdo neumí ten se to případně naučí ;-)

    Za sebe můžu práci doporučit. Je tu dobrý kolektiv. Celkem dost věcí jsem se tu naučil. Navíc air bank ještě nemá tak hrozné korporátní manýry jako jiné starší velké společnosti.

    Já jsem tady na IČO, takže nevím jaké benefity mají na HPP. Ale řekl bych, že to je klasika jako všude jinde. Jestli máte zájem tak mi napište a dám nějaké podrobnosti.

    link na ofiko inzerát (když se přihlásíte přes ten link a přežijete zkušebku, tak dostanu nějaký bonus k faktuře)
    Tester/ka bankovních aplikací (Praha) - Air Bank a. s. | Jobote.com
    https://www.jobote.com/cs/job/apyv7rx?
    Kliknutím sem můžete změnit nastavení reklam