Testování - metráková princezna, kterou nikdo nechce
|
Vývojová fáze | Provozní fáze |
||
Analýza požadavků | 3% | Provoz a údržba |
67% |
Specifikace | 3% | ||
Design | 5% | ||
Kódování | 7% | ||
Testování | 15% |
Co z toho vyplývá? Pokud pomineme to, že náklady na vývoj systému tvoří pouze jednu třetinu celkových nákladů během životního cyklu systému, náklady na testování tvoří 45% nákladů na vývoj. Jinými slovy, v okamžiku dokódování systému a jeho předání do testů jsme těsně za půlkou vývoje(!)
Osobnost testera
Testeři jsou jistým protipólem programátorů, což často vyvolává konflikty. Programátor přistupuje k programu pozitivně - věří, že program nemá chyby a doufá, že testy žádné chyby neodhalí. Tester ví, že program má chyby a jeho největší touhou je co nejrychleji je nalézt a přesvědčivě reprodukovat. Už to je dost dobrý důvod, aby se tyto dvě skupiny neměly rády.
Nejdůležitější pro testera je schopnost věcné argumentace a schopnost dosáhnutí opravy. Pokud je argumentace ze strany testera kontaminovaná kritikou osobnosti programátora nebo jeho schopností, pravděpodobnost opravy chyby se velmi snižuje. Tester musí být nápomocný a to se mu podaří hlavně tím, že odvede kvalitní práci při popisu chyby a její reprodukovatelnosti. Programátoři ocení vzorky dat, které systém spolehlivě "složí", stejně tak, jako popis celkového kontextu chyby (verze programu, globální nastavení, verze prohlížeče, jeho rozšíření, apod.).
Je v zájmu vývoje, aby tester zvážil, kterou bitvu má cenu bojovat, a kdy je rozumné ustoupit. Zvlášť destruktivní jsou eskalace, které mohou nezvratně poškodit produktivitu vývojového týmu. Těmi je zvlášť potřeba šetřit.
Testovací taktika
Jedna věc je na začátku testů jistá - nestihne se otestovat všechno, co bychom chtěli. To, co dělá z testů vědu je právě výběr toho, co se musí testovat. Proto je dobré, když už ve fázi požadavků analytici pracují s prioritami - ne každá chyba bolí stejně. Abychom mohli otestovat důležité funkce, často se musíme smířit s tím, že ty méně důležité testujeme s optimističtějším přístupem.
Výběr testovacích případů a jejich dokumentování je jednou z hlavních činností testera. Dobrý tester má instinkt, který ho vede při vytváření takových podmínek, ve kterých bude program nejspíš nefunkční. Mohou se týkat vstupních dat, periferií, komunikačního prostředí nebo čehokoliv jiného, s čím se bude muset program v provozních podmínkách vyrovnávat.
Tester potřebuje testovat na různých konfiguracích, proto je dobré slevit z korporátních pravidel, které určují, jaký pracovník na jaké pozici může mít notebook a/nebo PC s více monitory. Náklady na hardware jsou v porovnání s náklady na testování zanedbatelné.
Začínáte s vývojem systému?
Začínáte s testováním a necítíte se v něm silní? Můžu vám pomoct - radou, školením, vedením testů nebo samotným testováním. |
Přehled testovací dokumentace se stručným komentářem je sestavený podle standardu IEEE Standard 829–1998 for Software Test Documentation.
Cílem testování není vytvoření všech dále uvedených dokumentů. Cílem je co nejrychlejší nalezení co největšího počtu chyb. Cokoliv stojí v cestě tomuto cíli – a takovou překážkou může být i tvorba testovací dokumentace – je potřeba omezit.
Zpět na hlavní stranu