{jcomments on}Chtěl bych tu krátce shrnout mé zkušenosti a pocity s testovacím nástrojem, který se aktuálně jmenuje HP Quality Center. Ale nejmenoval se tak vždy.

Ale ta změna rozhodně není tak dramatická. Původně se tento nástroj jmenoval Mercury Quality Center. Jméno se do dnešní podoby (nepatrně) změnilo po roce 2006, kdy firma Hewlett-Packard koupila původního producenta tohoto nástroje, firmu Mercury Interactive. Z pohledu mě jako uživatele jde ale o změnu těžko postřehnutelnou. Tedy abych byl úplně přesný, tento nástroj se jmenoval také Test Director. Ale proč si to zbytečně komplikovat. Nástroj se jednoduše jmenuje Quality Center (dále jen QC) a jde o zástupce tzv. komplexních řešení.

QC je software, který v sobě sdružuje nástroje pro test management, správu požadavků i bugtracking. Všechny tyto nástroje tvoří integrální celek. Jsou mezi sebou provázané tak, že informace z jednoho se automaticky propisují do všech ostatních dotčených nástrojů a navenek QC vystupuje jako kompaktní nástroj pro komplexní správu QA.   

Aby toho nebylo málo je nutné si říct, že QC je součástí celé rodiny nástrojů určených pro podporu testování a které jsou nabízeny firmou Hewlett-Packard. Jde například o LoadRunner, WinRunner, QuickTest a další. Jde převážně o nástroje automatizovaného testování, které mohou být s QC přímo propojeny a vzniká tak opravdu robustní řešení pro firemní QA.

Já bych se tu ale rád soustředil pouze na QC. I tak je toho hodně, co se o tomto nástroji dá říct. QC byl prvním nástrojem testování , se kterým jsem vůbec v rámci své testerské kariéry pracoval. Musím se přiznat, že mě hodně nadchl a až do nedávna jsem byl přesvědčený, že to už o mnoho lépe udělat nejde. Mé nadšení se přeci jen o dost zmenšilo, ale k tomu později.

Jednou z největších výhod, které QC nabízí, je již zmíněná integrace více testovacích nástrojů. Snahou jeho tvůrců bylo pokrytí celého procesů testování od jeho začátku až po konec. Proto je zde k dispozici Správa požadavků, která umožňuje analytikům vkládat veškeré požadavky (funkční i nefunkční), které zákazník na vyvíjenou aplikaci má. Dalším z nástrojů, které jsou v QC k dispozici, je Release management. Ten je zde označen jen jako Management a slouží k vytváření a sledování záznamů o vydaných releasech testované aplikace.

Z hlediska testování jsou nejpodstatnější tři další nástroje, které QC nabízí. Tím prvním je Test Plán. Ten umožňuje vytvářet a spravovat testovací případy. Tento proces je tu velice dobře vyřešen. Jednotlivé testovací případy lze vytvářet, editovat, mazat. Je možné je ukládat do v celku libovolné stromové struktury, kterou lze v Test plánu vytvářet. Z mého pohledu je podstatné, že testovací případy jsou zde vytvářeny jako tabulka skládající se  z jednotlivých kroků. Tedy co jeden krok to jeden řádek tabulky. To není u podobných nástrojů vždy pravidlem.

každý krok testovacího případu může obsahovat volitelné množství údajů. Nejpodstatnějšími z nich jsou pochopitelně požadovaná akce, kterou má tester nebo automatizovaný nástroj provést, a očekávaný výsledek. Ty získávají na významu v okamžiku provádění testu, ale k tomu se dostaneme. Rád bych tu zmínil i práci s testovacími daty. Ke každému testovacímu případu je možné vložit testovací data, která jsou zde označená jako Testovací parametry. Formou aliasů (nebo proměnných) je možné tato data vkládat přímo do jednotlivých kroků testu. Díky tomu je možné  jednoduše vytvářet testy, které se od sebe liší pouze vstupními a výstupními daty. QC navíc umožňuje vnořování testů do sebe. Je tedy možné vytvořit například test logování a ten pak vnořit do všech testů, které pro svoje spuštění vyžadují právě logování.

Velice zajímavou součástí QC je Test Lab. Ta v podstatě slouží k samotnému testování. Testy, které byly v Test planu připraveny je tady možné spustit. Jejich spuštění a výsledek, s jakým skončily, se tu ukládá a je tak možné kdykoliv zjistit kolikrát, kým, kdy a s jakým výsledkem byl test proveden. Spuštění testu má z mého pohledu docela pěknou podobu. U manuálního testu jsou postupně zobrazovány jeho kroky přičemž tester po vykonání daného kroku zaznamená jeho výsledek. U každého testu je tak možné sledovat nejen jeho výsledek jako celku ale také výsledky jednotlivých kroků. To má velký význam v okamžiku, kdy test skončí s negativním výsledkem. V tu chvíli je možné přesně dohledat, ve kterém bodě testu nastal problém. U automatizovaných testů je zde možné spouštět skripty, které k nim byly vloženy v okamžiku vytváření.

Nalezené chyby je možné zaznamenávat v bugtrackingové části QC, která je označená jako Defects. Ta má v celku standardní podobu. QC umožňuje vytvářet vlastní workflow zpracování nalezené chyby. Formulář pro reportování chyby umožňuje přizpůsobení formou volitelných položek. Přehled chyb lze filtrovat a lze zde nastavit, jaké sloupce se v přehledu budou zobrazovat.

QC obsahuje také reportovací nástroj, který je zde nazvaný DashBoard.

Pozitiva

To co jsem tu zatím napsal ukazuje, že QC obsahuje celou řadu nástrojů, ale pořád to ještě neříká, proč by mělo jít o nějaký výjimečně dobrý testovací nástroj. Ale já to tu už zmínl. Nejsilnější zbraní, kterou QC disponuje, je integrace. Každá jeho část komunikuje a je propojená se všemi ostatními částmi. Poskytuje tak svým uživatelům poměrně komplexní pohled na celý testovací proces. 

Vytvářené testy lze provázat s existujícími požadavky. U požadavků je pak možné sledovat jejich pokrytí testy. Testy je zároveň možné navázat na nalezené chyby. To je dokonce ještě sofistikovanější než se zdá. V okamžiku kdy při běhu testu nalezne tester chybu, může ji přímo ze spuštěného testu nahlásit. Tato chyba je díky tomu navázána nejen na test, ve kterém se projevila, ale také na konkrétní krok tohoto testu. Vývojář, který danou chybu opravuje, tak může (chce-li) získat mnohem přesnější informaci o to, co předcházelo nalezení chyby. Díky release managementu je toto vše navíc možné propojit s konkrétními verzemi aplikace. 

QC funguje jako kompaktní celek a dá se říct, že skutečně funguje. Možnost rozšíření o další QA nástroje z nabídky HP z něj činí opravdu silné řešení celého QA.

Mezi pozitiva je možné zařadit i fakt, testy je  možné vytvářet mimo QC a do něj je následně importovat. Stejně tak je možné testy z QC exportovat a přenášet jinam. Tato funkčnost nebyla dlouhou dobu ze strany Mercury (resp. HP) dostatečně podporována. Export bylo například možné řešit pouze vytvořením vlastního exportního skriptu, který se připojil k API, které QC nabízí. Dnes je již vše řešeno poměrně komfortně.

Negativa

Já byl vždy velký fanoušek QC. Přesto po delší době jeho používání musím konstatovat, že má i několik negativních vlastností. Tak především je to jeho mohutnost. QC je opravdu velký nástroj, který se nemusí hodit vždy a všude. Jeho přínos je rozhodně největší u velkých projektů, velkých firem. I tam ale budou jeho uživatelé narážet na další, drobné, problémy. Alespoň mě tedy docela vadí celkové řešení zobrazování jednotlivých informací. Nevím jak to říci nějak sofistikovaně. Řeknu to jedoduše - QC každou chvíli, při každém odkliku do jiné části nástroje nebo i jen na jiný záznam v přehledu, něco načítá ze serveru. Při pomalejší síti nebo při větším zatížení je toto neustálé "sahání" pro data nepříjemné a může zdržovat.

Navíc je tu trochu zvláštně vyřešena souběžná práce více uživatelů. Pokud má například jeden uživatel otevřen přehled chyb a má označený (a tím i zobrazený) jeden ze záznamů v přehledu, blokuje tím tuto chybu pro ostatní uživatele. Ti si ji sice mohou prohlídnout, ale už ji nemohou editovat a to přestože uživatel, který si ji otevřel jako první si ji pouze prohlíží a nic v ní nemění.

Celkově se mi s bugtrackingem v QC nepracuje úplně nejlépe. Rozhodně existuje mnoho lepších nástrojů k tomuto účelu. Zmínit mohu například ne úplně ideální práci s filtrem, jehož nastavení je zde sice možné uložit (lépe řečeno uloží se v okamžiku jeho nastavení), ale není možné mít uloženo více filtrů najednou a přepínat se mezi nimi. Problém je i hledání chyby podle jejího čísla. To je zde totiž (na rozdíl o některých jiných nástrojů) řešeno opět jen jako nastavení filtru. Tedy pro hledání chyby podle čísla je nutné původní filtr vyčistit a nastavit nový s číslem chyby. 

Ono jde asi více méně o drobnosti, ale při dlouhodobější práci mě obtěžují. Nicméně uznávám kvality QC jakožto komplexního nástroje pro správu QA. Provázanost jeho jednotlivých části stále považuji za velice dobrý koncept.