devel.cz

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.