Na pracovních pohovorech se testerů velice rádi ptají, zda mají zkušenosti s nástroji. Existuje celá paleta různých nástrojů, které se dají využít k testování. Automatizované testování nebo například zátěžové testy se bez nástrojů neobejdou. Exitují i nástroje usnadňující analýzu. Používají se i nástroje pro přípravu dat, nebo pro testování zdrojového kódu. Existuje zkrátka celá řada nástrojů použitelných pro testování. Přesto tester, který má zkušenosti pouze s manuálním testováním, má tendenci říct, že nikdy žádný nástroj nepoužíval. S jedním typem nástrojů by ale určitě zkušenost mít měl. Jde o Bugtrackingové nástroje.

Fakt, že tester najde v softwaru chybu, sám o sobě nic neznamená. Tato informace se musí někam zaznamenat a musí se dostat dál. Ať už k vývojářům, kteří ji opraví, nebo k project managerovi, který celý projekt řídí, nebo i k zákazníkovi. A v zásadě k tomu slouží bugtrackingový nástroj. Už dříve se tu objevil článek o životu brouka, tedy o životním cyklu chyby od jejího nalezení až po její uzavření. Právě realizaci tohoto cyklu zajišťuje bugtracking. Ten umožňuje testerovi zadávat nalezené chyby. Ty jsou následně předány (automaticky nebo manuálně, to záleží na použitém programu) vývojářům k opravě. Od nich se informace o opravě dostane opět zpátky a tester pak potvrdí (nebo nepotvrdí) správnost opravy. To je úplně nejjednodušší způsob použití bugtrackingu. Samozřejmě do tohoto cyklu mohou vstupovat například analytici, kteří se podílejí na specifikaci nalezené chyby, project manager, který získává statistická data, nebo zákazník, který může hlásit chyby nalezené při reálném použití dodaného softwaru.

Dobrý bugtrackingový nástroj by měl být vybavený následujícími vlastnostmi:

1) Správa více projektů - není ideální pro každý projekt instalovat vlastní instanci stejného nástroje. Navíc jeden člověk se může podílet na více projektech a je pohodlnější vše řešit v jednom nástroji. 

2) Správa uživatelských práv - to vyplývá z předchozího. Pokud nástroj umožňuje současnou správu více projektů, je nezbytné zajistit, aby k projktu měl přístup pouze ten, kdo na něm reálně pracuje nebo má mít přístup k údajům z něho. 

3) Správa rolí - opět úzce souvisí s předchozím bodem. Každý člověk má na projektu přidělnou roli (např. vývojář, tester, manager, atd.) a každá role má stanovené činnosti, které může provádět. 

4) Správa workflow - tedy správa broučího života. Znovu souvisí s předchozím. Životní cyklus chyby se skládá buď přímo ze stavů (např. nová, opravená, schválená, atd.) nebo z přechodů mezi stavy (např. opravit, otestovat, schválit, atd.) a ke každému stavu nebo změně má přístup jiná role (např. vývojář může chybu opravit, ale nemůže ji schválit, tester ji může nahlásit i schválit, ale nemůže ji opravit). Nástroj by měl umožňovat zadání jednotlivých stavů a jejich přechodů a kromě toho také určení, které role mohou s chybou v daném stavu pracovat. 

5) Závažnost chyb - z pohledu použitého nástroje jde o drobnost, z pohledu použítí je to poměrně zásadní. Každá nalzená chyba musí být ohodnoce z pohledu své závažnosti. V závislosti na vnitřních metodikách, strategii projektu atd. by měli vývojáři přednostně opravovat chyby s vyšší závažností. Bugtrackingový nástroj by měl umožňovat zadávání této závažnosti přímo při hlášení nové chyby. Vhodná je i konfigurovatelnost číselníků závažností - různé projekty mohou vyžadovat různý stupeň podrobnosti při rozlišování závažnosti chyb. 

6)Statistika - z pohledu vedení projektu jde o klíčovou vlastnost, z pohledu testera je to spíše jen pomůcka. Nástroj by měl být schopen generovat tabulky se statistickými údaji o průběhu projektu (počty nalezených chyb v závisloti na čase, jejich závažnosti, stavu v rámci životního cyklu atd.) Vhodné je i to, když nástroj umí vygenerovat příslušné grafy. 

7)Správa verzí - není úplně nezbytný nějaký propracovaný release management. Přesto by mělo být zřejmé v jaké verzi aplikace (samozřejmě pokud testovaná aplikace je verzovaná) byla chyba nalezena a v jaké verzi je již opravena. 

Jen stručně bych tu rád uvedl pár nástrojů, se kterými jsem se potkal:

JIRA - tento nástroj mám rád. Je přehledný, snadno se s ním pracuje a přitom je poměrně propracovaný. Jsou zde velké možnosti nastavení, ať už ze strany administrátora (nastavení workflow,práv, projektu atd.) tak ze strany uživatelů (celá homepage je nastavitelná, mohou zde být různé výstupy ze statistik). Problém zde je, že administrace není úplně triviální.

ClearQuest - člen rodiny IBM Rational. Opět velice pěkný nástroj, minimálně pokud jde o vzhled a ovládání. Možná malinko nedotažené, aspoň z mého pohledu, je neustálé otevírání nových záložek. Každopádně je to z pohledu testera nástroj přehledný a snadno použitelný.

HP Quality Center - dříve Mercury Quality Center. Jde o výborný nástroj, vlastně jde o soubor propojených nástrojů, kde bugtracking tvoří jen část. Filozofií tohoto nástroje je pokrýt co největší oblast vývoje softwaru v jednom nástroji. Proto jsou zde evidovány již požadavky (ať už ze strany vedení projektu nebo ze strany zákazníka). Od požadavků se odvíjejí testy, které tyto požadavaky pokrývají. Quality centrum umožňuje vytváření testovacích skriptů přímo uvnitř toho nástroje. Tyto skripty mohou být vnořovány do sebe, pokud se například jedna činnost v ránci skriptů stále opakuje (typicky přihlašování). Není tedy nutné stejné kroky psát stále znovu. Navíc je zde možnost přímo ke skriptům připojit pomocí proměnných testovací data. Testovací skripty jsou v tomto nástroji také spuštěny. Jsou evidovány všechny průběhy testů a je tedy k dispozici přesná statistika, kolik testů bylo provedeno a s jakým výsledkem. Díky tomuto přístupu zde funguje také poněkud jinak samotný bugtracking. Chybu je možné hlásit přímo z testu, kde byla nalezena a je přitom navázána na konkrétní test a konkrétní krok v daném testu. Chyba je tak mnohem lépe lokalizovatelná, než když tester svými slovy popisuje, kde k ní došlo. Je také mnohem snadnější provést retest chyby.

Merant Tracker - tady jen stručně, tento nástroj mě moc nenadchnul. Na rozdíl od těch předcházejích není web based. Což ale není jeho chyba. Problém, který s ním má, vyplývá z jeho nepřátelskosti. Neposkytuje žádný komfort ani při zadání chyb, ani při jejich následném hledání v přehledech. Znám hodně lidí, kterým tento nástroj vyhovuje. Já k nim ale nepatřím.