Testování je, jak už tu bylo mnohokrát řečeno, nedílnou součástí procesu vývoje softwaru a to bez ohledu na to, jakou metodikou se tento vývoj řídí. Aby bylo možné celý proces vývoje úspěšně plánovat, musí pro každou jeho část existovat smysluplný odhad pracnosti. Tester by tedy měl být schopen, ještě před začátkem samotného testování, odhadnout míru pracnosti resp. časovou náročnost testování pro daný projekt/etapu vývoje/iteraci atd. Přístupů, které k tomuto odhadu vedou, je několik.

Pokud chceme odhadnout pracnost čehokoli, tedy i testování, zajímá nás v první řadě, o jak velký objem práce jde. A to není na začátku celého procesu až tak snadné říci. Proto se používají metody, které umožní získat představu o rozsahu testování. Tou nejzákladnější metodou je odhad na základě Funkčních bodů.

Funkční body představují metriku, jakou je možné měřit velikost aplikace. Abych byl přesnější, jde o mezinárodně uznávanou metriku, která je uznána i ze strany ISO. Existuje dokonce i organizace, která používání metody funkčních bodů zastřešuje (IFPUG). Samotná metoda stanovení počtu funkčních bodů není úplně triviální. Stručný úvod do ní naleznete zde. Získaná suma funkčních bodů představuje obecný odhad velikosti aplikace. Z hlediska testování se dá říct, že otestování jednoho funkčního bodu zabere určitý čas. O jaký čas jde konkrétně vychází ze zkušenosti testera, který odhad vytváří. Není na to totiž obecný vzorec. Vždy se jedná o záležitost takříkajíc individuální. Na základě předchozích zkušeností z podobných projektů, lze pracnost vztaženou k jednomu funkčnímu bodu odhadnout. Samozřejmě čím delší a větší je zkušenost testera s touto metodou, tím přesnější odhad získá. Nicméně takto získaná pracnost testování jednoho funkčního bodu se pak jednoduše aplikuje na celou velikost aplikace a tím získáme odhad pracnosti testování.

Jsou zde zjevné výhody i nevýhody. Výhodou je, že jde o vcelku jednoduchou a rychlou metodu, jak získat odhad pracnosti. Nevýhod je ale víc. Tou největší je zřejmě fakt, že se v této podobě s odhadem velikosti aplikace snad nikde nesetkáte.

Bylo by samozřejmě ideální, pokud by zadavatelé projektů, projekt manageři nebo business analytici tuto metodu ovládali natolik, aby dokázali relevantně vyčíslit funkční body plánované aplikace. Realita je samozřejmě taková, že funkční bod je ve skutečnosti určitá požadovaná funkčnost. Tester tak získá představu například o počtu a formátu vstupů a výstupů a základní představu základních funkčnostech uvnitř plánované aplikace. Na základě toho může, s použitím zkušeností z předcházejících projektů, rámcově odhadnout pracnost. Je asi zřejmé, že se tím podstatně snižuje přesnost takového odhadu. 

Ale i pokud je tato metoda aplikována striktně podle jejích pravidel, jsou zde určité nevýhody, které její přesnost snižují. Jde především o fakt, že se u ní nezohledňují různé druhy testování. Metoda odhadu pomocí funkčních bodů funguje čistě na poměru - pracnost testování na jeden funkční bod. Nezohledňuje se tedy fakt, že některé druhy testování jsou časové náročnější než jiné. Stejně tak není zohledněn typ aplikace. Dvě aplikace mohou být co se do počtu funkčních bodů stejné a tedy i dohad pracnosti testování by u nich byl stejný. Ovšem pokud nám takto vyjdou například dvě aplikace z nichž jedna je webová a druhá například čistě databázová, víme, že testování těchto dvou aplikací není srovnatelné.

Poněkud blíže realitě testování (a obecně reálnému životu) je metoda odhadu pracnosti pomocí seznamu Test Casů. 

Z pohledu testera jde o metodu přeci jen přirozenější než funkční body. Buď na základě analýzy nebo informací od business analytika (případně project managera) vytvoří základní seznam testovacích případů, které bude nutné nad aplikací provést. Každý takto získaný testovací případ se pak dohaduje samostatně. Nejde tedy o to, že paušální pracnost na jeden testovací případ se při deseti testovacích případech jen vynásobí deseti. Pro každý testovací případ se zvlášť stanoví odhad pracnosti. Pokud by měl být takový odhad co nepřesnější, měly by se pro každý testovací případ stanovit až tři dohady a to pro normální průběh, pro průběh v ideálním případě i pro nejhorší možný případ. Průměr získaný z těchto tří odhadů dává poměrně přesnou představu o reálné pracnosti daného testovacího případu.

Výhody jsou asi zjevné. Jde o metodu, která respektuje různé druhy testů a je přímo vázána na testovací případy. Není tedy obecná, jako metoda funkčních bodů. Nevýhodou je, že samotné vytvoření seznamu testovacích případů má svoji jistou, a ne vždy zanedbatelnou, pracnost. Navíc počet testovacích případů se může v průběhu procesu vývoje měnit a tím se samozřejmě musí měnit i odhad pracnosti. Jako nevýhodu můžeme, trochu paradoxně, brát i fakt, že jde o metodu vázanou na konkrétní testovací případy. Tedy přesně to, co jsme před chvílí označil za výhodu této metody. Jde o to, že u metody funkčních bodu se její přesnost postupně zlepšuje (s počtem dokončených projektů) a díky tomu a faktu, že je založená na obecném odhadu pracnosti na funkční bod, lze projekty mezi sebou velice dobře porovnávat. Díky tomu je možné například získat informace o reálné efektivitě jednotlivých týmů a podobně.

Každopádně já se s odhadem pomocí seznamu testovacích případů setkávám nejčastěji.

Velice častým způsobem odhadů pracnosti je odhadování na jednotlivé úkoly. Testování je rozloženo na dílčí úkoly a pro ně odhadnuta pracnost. Může jít například o úkoly typu: Příprava testovací dokumentace, Příprava testovacích dat, Instalace testovacího prostředí, Smoke testy, 1. kolo testů, 2. kolo testů, Performance testy, Vyhodnocení testů atd. Každý tento úkol je samostatně posuzován z hlediska jeho pracnosti. Opět je vhodné stanovit si odhad pro nejhorší a nejlepší variantu a tyto odhady zprůměrovat.  

Tento přístup má nejblíže k reálnému plánování projektu. Upřímně řečeno project managera příliš nezajímá jaké konkrétní testy bude tester provádět. Pro řízení projektu je důležitější vědět, jaké úkoly v jakém pořadí a jak dlouho budou v rámci testování probíhat. Tato metoda je tedy nejlepší pro vytváření projektového plánu a díky tomu k včasnému odhalení možných zpoždění. Nevýhodou je, že se pracuje pouze s obecnými úkoly. Bez hlubších znalostí a zkušeností není příliš reálné získat relevantní odhad. Tato metoda má největší význam u týmů, které řeší stejné nebo podobné projekty. Zde by naopak takto získaný odhad byl poměrně přesný.

Metod odhadu pracnosti testování existuje mnohem víc. Já jsem vybral pouze ty, které jsou mi blízké. Tedy ty, se kterými jsem se nějaké podobě již setkal. Z mého pohledu je ideální kombinovat odhad na jednotlivé úkoly a odhad na testovací případy. Záleží ovšem na tom, jak velká důležitost je kladena na rychlost získání odhadu a na jeho přesnost. Vždy jde o kompromis. 

Rád bych tu ale uvedl jednu věc, která mě vlastně k napsání tohoto článku přivedla. Na jednom z posledních projektů jsem narazil na odhady pracnosti testování, které nebraly v úvahu opravu nalezených chyb. Jiank řečeno odhady byly dělány pouze na čistý čas provedení naplánovaných testů. Čas na opravu defektů nebyl zahrnutý ani do odhadů pracnosti vývoje. Oprava každé chyby tak znamenala nárůst zpoždění projektu. Je záležitostí project managera, jakým způsobem řídí projekt. Ovšem tester by při svých odhadech měl vzít v úvahu fakt, že testování nekončí, dokud nejsou opravené chyby. Setkávám se s tím, že vývojáři svou práci odhadují v tzv. čistém času. Odhadnou prostě jak dlouho jim bude trvat vývoj požadované funkčnosti. Tester ale musí své odhady (minimálně v té rovině odhadů nejhoršího možného průběhu) vytvářet v reálném čase. Ten musí zohledňovat například problémy se získáním testovacích dat nebo testovacího prostředí, možnost nebo nemožnost souběhu různých druhů testování (například regresní a perfomance testy na jednom prostředí) a již zmíněnou opravu chyb.