Penetrační testy teď nabízí kde kdo, jak ale poznat, kdo je opravdu umí provést a kdo na nich chce jen vydělat?

První, co vám mohu doporučit, prověřte si danou firmu a uvedené reference. Určitě kontaktujte osobu, která je v referencích uvedena a zeptejte se jí, jak byla s prací dané firmy spokojena, a co přesně bylo předmětem dodávky. Uvědomte si, že analýza rizik (risk analyses), prověrka konfigurace (configuration review) nebo skenování zranitelností (vulnerability scan) je něco jiného než penetrační testování nebo chcete-li ethical hacking.

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.

V tomto krátkém příspěvku se dozvíte, k čemu slouží Protokol o předání SW k testování (test item transmittal report) a jaké náležitosti by měl obsahovat.

Důvod existence tohoto dokumentu je prostý. Vlastní testování bude nejspíš provádět někdo zcela jiný, než kdo plán testování, testovací scénáře, testovací případy a testovací skripty navrhoval.

V tomto krátkém příspěvku se dozvíte, co je to testovací skript a co by měl dokument popisující testovací skript obsahovat.

V okamžiku, kdy se všechny nebo některé požadavky testují automatizovaně, obvykle se k tomu používá nějaký speciální SW nebo skript. Každému takovému skriptu by měl být přidělen jednoznačný identifikátor a mělo by být popsáno, k testování jakých požadavků slouží.