- 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 dopady
Akceptační kritéria ze smlouvy
Postup test analýzy
- Definice požadavků a jejich navázání na Use Cases
- 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 target
Prá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ší dotazy
Vý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