Cílem tohoto testu je zjistit, jak se systém bude chovat v reálném provozu, kdy k němu bude současně přistupovat velké množství uživatelů.

Ze zkušenosti mohu říci, že na některé chyby se dá přijít až v okamžiku, kdy je k danému systému přihlášeno velké množství uživatelů, kteří současně využívají služeb, které daný systém poskytuje.

V tomto příspěvku se podíváme na automatizované testy aplikací typu klient-server, které mohou být v zásadě dvojího typu.

V obou případech musíme na nějakém stroji spustit robota, který bude automatizované testy provádět. Rozdíl spočívá pouze v tom, že buď bude robot simulovat uživatele dané aplikace nebo stroj, který uživatel používá.

Usability test, nebo chcete-li testování použitelnosti, patří do kategorie testů typu black box. Bohužel jen málokdo jej umí zrealizovat.

Stále se najde dost firem a manažerů, kteří jsou přesvědčeni, že provádět usability testy je naprostá ztráta času a vyhozené peníze, protože nikoliv uživatel, ale oni a jejich vývojový tým nejlépe ví, jak má uživatelské rozhraní vypadat.

Myslíte si, že když úspěšně otestujete přechod na novou verzi systému a v rámci testování se neobjeví žádné problémy, že máte vyhráno?

Vězte, že problémy se obvykle objeví až po nějaké době používání a v některých případech jsou dokonce takového rázu, že není jiné cesty, než se zase vrátit k předchozí funkční verzi. Možná si teď říkáte, v čem je problém, máte přeci zpracovaný a otestovaný DRP a sekundární server pro případ výpadku. Nainstalujete na něj předchozí verzi, uživatele přesměrujete na něj a nikdo si ničeho ani nevšimne. 

Co je to test status report? Jednoduše řečeno, jedná se o zprávu o výsledcích testování, kterou zpravidla Test manager předkládá vlastníkovi.

Stejně jako všechny ostatní dokumenty, které v rámci testování vzniknou, i tento dokument by měl obsahovat jednoznačný identifikátor. Vzhledem k tomu, že ne vždy se povede plán testování dodržet, mělo by se ve výsledné zprávě objevit, co přesně se testovalo a kdo, kdy, kde a jak testování prováděl. Jedině tak je možné splnit podmínku opakovatelnosti a měřitelnosti.

V tomto příspěvku se dozvíte, co je to defect management, jaký je životní cyklus defektu. Co je to test incident report a jaké informace by měl obsahovat.

Vzhledem k tomu, že ne vždy test projde, je potřeba mít definován závazný postup, jak tento stav řešit. Vznešeně se této činnosti říká defekt management (defect management). V podstatě jde o to určit, kdo, komu a jakým způsobem by měl defekty hlásit a jak by s nimi mělo být dále nakládáno. Pokud se nepoužívá na správu defektů žádný pokročilý SW nástroj, vytváří se tzv. test incident report, ve kterém by mělo být uvedeno:

V tomto krátkém příspěvku se dozvíte, k čemu slouží Testovací log a jaké informace by měl obsahovat.

Testovací log poskytuje informace o průběhu jednotlivých testů. Testovací log by měl mít jedinečný název, aby nedošlo k záměně s logem z jiných testů, z jiného časového období nebo od jiného testera.