Test analýza Zajistí efektivní vedení testů včetně určení jejich rozsahu Definuje cíle projektu a požadavky na testování Identifikuje a omezuje rizika plynoucí z neotestování některých fází Napomáhá kontrole nad celým projektem Zkoumá i potřebné zdroje jak technické, tak lidské Posuzuje realizovatelnost akceptačních kritérií

Test analytik Vychází z uživatelských požadavků na základě use cases Use cases jsou namapovány IT analytikem Určuje nejvýhodnější a nejefektivnější způsob testování a typy užitých testů Oblasti, o kterých rozhodne netestovat, ještě vyhodnotí z pohledu projektových rizik Provádí revizi analytické dokumentace proti byznys požadavkům Vytváří dokument plán testů

Test designer Na základě informací z detailního návrhu a vybraných požadavků na testování určí,

jak bude testovací případy připravovat, za po jednotlivých funkčnostech nebo po byznys transakcích

Spolupracuje na identifikaci rizik pro netestované oblasti Definuje požadavky na testovací prostředí Určuje testovatelnost a náročnost provedení testů

Test implementer Skládá testy do testovacích sad Testovací sady skládá do posloupnosti navazujících funkčností Testovací sady je též možno skládat dle schopností a oblastních znalostí jednotlivých

testerů Dále specifikuje HW požadavky a SW požadavky na testovací prostředí a koordinuje

jeho přípravu

Procesy test analýzy

Mise Definuje cíl a účel testování Je za ni odpovědný test manažer

Strategie Určuje způsob provedení testování i v závislosti na čase Určuje jednotlivé typy testů pro daná stádia testů Je prací test analytika a test designera Rozhodnutí se zapisují do plánu testů V závislosti na zvoleném typu testu se řeší výběr testovacího nástroje Zabývá se součinností a kompetencí jednotlivých rolí Určuje způsob vyhodnocení testů v závislosti na předmětu a cíli testování

Popis strategie Přístup k testování (úrovně, typy, forma) Role, kompetence, procesy Akceptační kritéria a proces akceptace

Plán testovacích kol (iterací) Zařazení testovacích sad do testovacích kol Odhady na náročnost testů (upřesnění potřeby zdrojů) Rizika neprovedení testů

Určení hlavních milníků testování

Vstupy pro test analýzu V praxi často neúplné U starších aplikací musí stačit uživatelská příručka a aplikace samotná Čím více chybí podkladů, tím je nutná složitější spolupráce se zadavateli

Funkční dokumentace Požadavky IT solution Use Case model, funkční specifikace Business zadání

Technická dokumentace Design Architektura systému Detailní návrh, algoritmy Datový model

Změnové řízení a jeho dopadyAkceptační kritéria ze smlouvy

Postup test analýzy1. Definice požadavků a jejich navázání na Use Cases2. Definice scénářů a jejich přiřazení k požadavkům na testování Provázáním testovacích požadavků na US nebo BU požadavky a vlastní testovací

případy získáme přehled o jejich pokrytí testy a stavu testování v daném čase

Červené: artefakty akviziční části projektu

Modrá projektové fáze projekce Zeleně projektová fáze konstrukce Žlutě fáze provedení testů Trarovatelnost dokumentace usnadňuje zpracování změn schválených změnovým

řízením do navrženého řešení => snížení pracnosti Trasovatelnost umožňuje určit v jednotlivých fázích projektu připravenost testovací

dokumentace pomocí pokrytí požadavků na testování již dokončenými testy a míru otestovatelnosti v libovolném čase

Test targetPráce s definicí požadavků na testování

Vybere se příslušná funkční oblast Přidají se k vybrané oblasti všechny požadované funkčnosti využívané ze stromové

struktury požadavků Navázání na požadavky na SW Pro každý test target se určí úroveň a typ testu

Typy testů Rozdělení testů dle zaměření Rozlišení dle koncepce FURPS Rozhodnutí, které oblasti rizik budou pokryty

Test case Musí obsahovat veškeré náležitosti týkající se provádění a nastavení samotného testu Nutnost provázání s příslušným požadavkem na testování Umožňuje podrobněji určit pracnost testu a rozdíly proti předpokladu řešit s vedoucím

projektu Pokud dojde k navýšení potřeby času, tak se řeší priorizací testů, nebo oddálením

termínu dodání systému Musí být srozumitelný

Popis případu Popis testu Podmínky před a po spuštění Testovací data Požadavky na prostředí Očekávané výsledky Kontrolní body, metriky Odkaz na test target

Řízení testů Používá priorit, rizika neprovedení/selhání testu Odhad náročnosti testu

Tvorba testovacích kroků Patří do fáze přípravy testů Každý krok testu obsahuje vstupní data a očekávaný výstup Definovány z USE Case a podrobnosti z funkčního protokolu Podrobnost zpracování musí odpovídat znalostem testerů Důležité je psát jednotlivé kroky, vstupy a výstupy, vazbu na test case

Automatizované testy se připravují tam, kde je často opakován test bez změny jeho GUI rozhraní

Konkrétní kroky, které mají být testerem vykonány

Častý obsah testovacích kroků Popis kroku a očekávaný výsledek Slovní popis pro manuální testy Spustitelný skript pro automatizované testy Skript ve formě SQL dotazu Kombinace předchozích Vazbu na test case

Test data Při definici dat se zohledňuje i možnost jejich opakovaného užití Dělíme na destruktivní a nedestruktivní Problémem je příprava dat ve sdíleném testovacím prostředí pro více projektů Sumární specifikace – data, která budou užita pro test Připravují se správné i chybové hodnoty na mezních stavech Data je třeba zajistit před zahájením testování Často data dodává zákazník, využívá produkční data Před testováním je nutné ověřit použitelnost dat Pokud se data nepřipraví s dostatečným předstihem, hrozí zpoždění nebo zmaření

testu

Konfigurace testovacího prostředí Jsou architektem specifikovány již v akviziční části a je postupně upřesněno Akviziční testy probíhají u zákazníka Specifikaci upřesňuje test implementor Prostředí musí být připraveno s předstihem, aby bylo možné připravit test data Za přípravu prostředí odpovídá správce test prostředí, na straně zákazníka jde o

pracovníky IT provozu Na sdíleném test prostředí se objevuj stejné problémy jako na sdílených test datech Popis HW a SW konfigurace a nastavení aplikace Je klíčové pro integrační testy mezi více systémy Důležité pro instalační testy Klíčové pro performance a load testy

Příklad parametrů test prostředí Výkon PC Internet a prohlížeč Verze Java Verze .Net Framework Orace klient

Upozornění Pozor na verze, vždy je nutné si ověřit jaký je cílový stav konfigurace na testovacích

stanicích Koncové stavy na testovacích stanicích by měly odpovídat stanicím uživatelů

Realizace Je-li vše připraveno, je test spuštěn Tester zaznamenává vše do testovacího protokolu test log V případě zjištění neshody se provede záznam o neshodě a do protokolu je zapsáno

ID neshody Vhodně nastavené parametry záznamu o neshodě a test logu umožní efektivní

vyhodnocení testu

Vyhodnocení a zpracování změn Test manažer a test analytik sledují průběžný stav testů, počty úspěšných proti

neúspěšným testům, počty a závažnosti nalezených chyb, typ identifikovaných chyb aby mohli rozhodnout o případném zastavení testů při přílišném výskytu chyb závažnosti kritická

Každá iterace se musí vyhodnotit, aby byla jasná otestovanost zkoumaného řešení Průběžné hodnocení slouží k povolení přechodu do vyššího stádia testů Na konci se provádí sumární vyhodnocení testů, aby se při řešení obdobného

problému předešlo chybám již identifikovaným

Cíle vyhodnocení Zajistit kvalitu produktu Zlepšit proces testování – probíhá v každé iteraci

Na základě vyhodnocení se provádí Úprava a doplnění test cases, skriptů a dat Doplnění o další potřebné testy (doplnění performance testů o tress testy, výkonnostní

testy) Automatizace testů

Test result a test log Vznikají ve fázi testování ve všech stádiích testů Test log – záznam testu Test result – výsledek analýzy test logu

Nástroje podpory testů MS Office (Word a Excel) HP Quality Center – komerční test manažer tool Vlastní vyvíjené utility JIRA – komerční bug tracking nástroj Bugzila – oupensurse bug tracking nástroj

Nejčastější dotazyVýběr testovacího nástroje

Zvažovat potřeby a možnosti projektu i zákazníka Soustředit se na výši nákladů (zaškolení) X využití nástroje

Jaká je třeba dokumentace pro analýzu Plán projektu, smlouva – především rozsah projektu a akceptační kritéria IT Solutin – IT analýza – požadavky, Use Case model, funkční specifikace, detailní

design Architektura systému, popis prostředí

Použití aparátu Viz kapitola postup analýzy

Existují další šablony Metodika RUP Metodika zákazníka (existuje-li) Dokumenty, které užíváme na projektech

Nedostatek dokumentace Je třeba dokumentaci získat od analytiků, nebo vývojářů Sejít se s uživateli, zadavateli, administrátory systému a získat potřebné informace

Nadbytek dokumentace Soustředit se na cíle testování a na jejich základě na příslušné kapitoly podkladů

Určení formy testů Vždy závisí na typu, době trvání a ceně projektu, zvyklostech a potřebách zákazníka Uplatňujeme přístup Good Enough Qvality