Institut testera/testovacího oddělení rubrika: Folklór

5 pilif
položil/-a 4.3. 19:02

Zdravím ve spolek,
poprosil bych o názor na tuto situaci:
Máme 2 relativně rozsáhle produkty typu ERP, dále nějaké další cca 3 až 4 produkty z oblasti výroby.
Jeden stávající ERP je již v provozu cca 20 let a nyní začínáme s jeho přepisem.
Pracujeme ve třech týmech napříč různými technologiemi (programuje se ve dvou diametrálně odlišných prostředích).
Unit testy jsou praktikovány pouze u jednoho týmu na jednom projektu.
UI automatizované testy neexistují.
Doposud byl systém ten, že vývojář si to naprogramoval, napsal dokumentaci a otestoval. Tím byl úkol označen jako "Done" a předán zákazníkovi.

Moje úvaha:
Základní testování samozřejmě vývojář musí udělat sám. Následně se řekněme nová funkčnost s popisem předá "testerovi", ten vytvoří přesně popsané testovací scénáře. Podle nich se pak budou provádět testy dle určitých pravidel/plánu. Současně popsané scénáře budou sloužit jako sekundární dokumentace.
Tyto testovací scénáře by mohly dále sloužit pro zaškolení nových zaměstnanců např. na pozici konzultanta anebo i samotných nově přijatých vývojářů, aby dostatečně rychle pronikli do business logiky.
Samotný "tester/testovací oddělení" by pracovalo napříč produkty a týmy.

Jak se toto např. řeší u Vás. Nebo "testery" třeba vůbec nemáte?
Je vůbec akceptovatelné u rozsáhlých ERP projektů s velmi dlouhou životností testery nemít?

Díky za názory.

odkaz Vyřešeno
9 Žížala
odpověděl/-a 6.3. 7:51
 
upravil/-a 6.3. 7:54

Píši novou odpověď na Vaši reakci, jelikož to formátování komentů je tady stále na nic.

Tester může a nemusí být člověk obeznámený s programováním. Záleží na typu testování. Ale co se týká týká vás, podle toho co popisujete, je spíše black box testing, ITG a UAT. A tam to není moc potřeba. UNIT testy nechte vývojářům, tak to má být. Ale na vše ostatní si dejte nové lidi, nezatížené vývojem/vztahy s kolegy. Jinak budete ve firmě zažívat "ty vole, jsme na tom dělali spolu, tak co mě s tím otravuješ, si to můžeš opravit sám".

Testeři mezi námi programátory nejsou tak úplně oblíbení, jelikož nám reportují chyby a to je "kua co mě s tím otravuješ, já to mám dobře to ty jenom blbě testuješ a vymýšlíš debilní testy to normální člověk do toho formuláře nezadá".

Testeři testují, neprogramují a pokud nedělají gray/white box testing, tak nemusí mít o kódu páru.

Testeři si musí být schopni připravit testovací prostředí ve spolupráci s adminy. např. nachystat data, udělat change a spustit testy. Např. sjet roční uzávěrku s/bez modifikací a pak udělat komparační testy DB. Zjistit případné side efekty. Na ty by měl ale upozornit již architekt změny a tester je jenom ověřit.

Základ úspěchu testování je si uvědomit jaké testy potřebujete udělat a podle toho zvolit způsob testování:

  • Někdy stačí obyčejné funkční testy: "Po kliknutí na tlačítko Odeslat, se pošle email. Naše mailové rozhraní ho zpracuje a pošle adresátovi".
  • Jindy potřebujete komparační testování: "byl nasazen nový způsob výpočtu úroku u produktu XYZ a na účtech používající tento produkt musí být po jetí měsíční uzávěrky nově tato částka". Takže jedete 2 testy, jeden na starém kódu, uložíte data, pak nainstalujete nový kód a sjedete novu uzávěrku a zkontrolujte, zda se změnila částka pouze na účtech podléhajích novému úroku a ostatních účtů se změna nedotkla.
  • Přijde požadavek "nějak nám poslední dobou jede pomalu výpočty ve směnárně" a vy rázem děláte stress testy a hledáte úzké hrdlo. Je to slabým výkonem HW? Je DB v dobré kondici? Je moc paralelních požadavků? Špatný memory management? Je dobře nakonfigurovaný garbage collector? Tuhne nějaké API do XYZ?

Tohle jsou běžné požadavky na testery a jak vidíte, není potřeba programovat. Ale analyzovat a umět udělat rozvahu strategie testování.

Jiná situace je, když aplikace padá na hubu při nějakém sledu operací, ale ne vždy. Tady už je potřeba spolupráce s programátorem, a proto jsem psal, že je zapotřebí mít komunikační osobu v programátorském týmu. Tester si vezme si k ruce programátora a projde s ním jednotlivé testovací scénáře podle zjištěných okolností pádu. Na jednotlivé případy pak nasadí potřebné nástroje jako statspack, JVM monitor, MQMonitor apod. Tyto nástroje jim pomůže vývojář vybrat, protože on by měl mít tušení, kde je zahrabaný pes. Ve spolupráci s adminy se nastaví různé monitory HW/SW prostředků. A vesele začne testování. A pak např zjistíte, že aplikace vytváří zbytečně miliony stringových objektů, dojde paměť, je tam smyčka nekonečná(viz nekonečná smyčka) apod. A tady se hodí mít nějaké programátorské zkušenosti, protože nemá cenu mít po celou dobu průběhu testů a prvotního vyhodnocování výsledků programátora. Ale to už je dost velké specifikum, na které by v zásadě nemělo dojít, ale může nastat. I bez viny programátorů, jenom třeba proto, že byla vyměněna nějaká komunikační komponenta od jiného dodavatele a on neudělal pořádné ITG.

Komentáře

  • pilif : Ad) testerem bývalý programátor: zde bych se neobával té vazby na to, že se účastnil nějak výrazně programování. Jde z části také o to, že jako programátor moc neuspěl a chtěli bychom pro něj najít jinou vhodnou roli. Samozřejmě je také otázkou jestli neuspěl jako programátor nenaznačuje jisté riziko pro pozici testera :) To ovšem nijak nenaznačuje, že roli testera vymýšlíme jen proto abychom jej "uklidili". 6.3. 18:08
  • Žížala : Pokud jde o takovýto "problém", tak je to OK. Ne každý mám programátorské buňky, někoho to může zlákat, ale prostě mu chybí to správné myšlení a/nebo zápal... 7.3. 6:25

Pro zobrazení všech 9 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.