Tento článek přináší odpověď na otázku, jak zajistit bezpečnost dat ve vývojovém, testovacím a produkčním prostředí a úspěšně zvládat rizika, která jsou s provozem těchto prostředí spojena.

Je třeba si uvědomit, že každý SW prochází zpravidla během svého vývoje několika různými prostředími. Běžně se jedná o vývojové, testovací a produkční prostředí. Vzhledem k tomu, že testovací prostředí se může ve velkých společnostech dále dělit na integrační a akceptační, jsme postaveni před poměrně nelehký úkol:

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.

Společnost je v období krize velice zranitelná, její informační aktiva jsou více než kdy jindy ohrožena neboť výrazně roste riziko narušení důvěrnosti, integrity a dostupnosti dat ze strany vlastních zaměstnanců i konkurenčních firem.

Vzhledem k tomu, že v období krize obecně klesá poptávka po určitých produktech a službách, snaží se společnosti nabízet jen ty produkty a služby, o které je zájem a udržují jen takový stav zaměstnanců, aby byly schopny tuto poptávku uspokojit. Vyšší než nezbytně nutný počet zaměstnanců udržují jen kapitálově silné společnosti nebo ty, co jsou ochotni se dočasně spokojit s minimálním nebo žádným ziskem. Naprostá většina společnosti však nadbytečné zaměstnance propouští.

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ží.

V tomto příspěvku se dozvíte, co je to testovací scénář a jak se testovací scénáře vytváří.

Testovacímu scénáři by měl být přidělen jednoznačný identifikátor a měl by obsahovat odkaz na Plán testování (ten by zase měl jednoznačně identifikovat testovací scénáře). Testovací scénář je tvořen sadou testovacích případů. Může se jednat o testovací případy, které na sebe navazují a musí být vykonány v přesně uvedeném pořadí. Nebo na pořadí, v jakém jsou jednotlivé testovací případy prováděny, nezáleží.

V tomto příspěvku se dozvíte, co je to testovací případ, jaké typy testovacích případů máme a jaké informace by měl testovací případ obsahovat.

Testovací případ (test case) definuje postup, jak otestovat daný požadavek. Pokud hovoříme o požadavcích, máme na mysli funkční a nefunkční požadavky uváděné většinou v SRS (Software Requirements Specification) dokumentu. Testovací případ popisuje, jak otestovat požadovanou funkčnost, to znamená, co má být zadáno na vstupu a co lze očekávat na výstupu. Testovací případy si můžeme rozdělit na logické a fyzické.

V tomto příspěvku se dozvíte, co je to testovací plán, plán testování nebo chcete-li plán testů, jaká je jeho struktura a jaké informace by měl obsahovat.

Hned v úvodu bych chtěl zdůraznit, že plán testování není nic jiného, než dokument, který slouží k popsání toho, co se bude testovat a to kdy, kde, jak, kým a čím. Vzhledem k tomu, že testovacích plánů může vzniknout několik a dokonce v různých verzích, obzvlášť ve společnostech, které se vývojem a testováním SW zabývají, je nutné zajistit, aby se vždy pracovalo se správným testovacím plánem.