4. Lekce Dílčí procesy funkčního testování

Prezentace na téma: "4. Lekce Dílčí procesy funkčního testování"— Transkript prezentace:

1 4. Lekce Dílčí procesy funkčního testování

2 V této lekci se dozvíte:
jak se testy připravují a plánují podprocesy funkčního testování jak se funkční testy realizují – manuální a automatizované provedení vyhodnocení testů ukončování funkčních testů Klíčová slova lekce: funkční testování, plán testů, testovací případy, automatizované testy, manuální testy Čas potřebný k prostudování lekce: cca 1 hod

3 Obsah 1. Funkční testování v životním cyklu SW
2. Plánování a příprava funkčních testů 2.1 Plán testů 2.2 Testovací případy 3. Realizace funkčních testů 3.1 Manuální 3.2 Automatizované 3.3 Fáze sledování a řešení neshod 4. Ukončení funkčních testů 5. Závěr 6. Kontrolní otázky

4 1. Funkční testování v životním cyklu SW

5 Aktivity procesu testování v rámci projektu
Zopakujme si podprocesy a aktivity procesu testování v rámci projektu: Plánování testů – má tři stupně: V akviziční fázi - jde o hrubé naplánování aktivit do času (základní milníky testování), předběžný odhad pracnosti na všechny aktivity procesu testování a základní předpoklad strategie testů především potřebné typy testů. Ve fázi Projekce – jde pak o upřesnění odhadů z akviziční části (je možné provést z nově vzniklých požadavků na testy), vzniká dokument Plán testů, později při přípravě testů je vytvořen podrobný harmonogram testů. Ve stádiu Realizace testů – jsou po každé iteraci (dle výsledků testů) upravovány plány testů, jak z hlediska obsahu testů pro další iteraci, tak z hlediska celkového času na testy. Příprava testů probíhá ve třech oblastech: Příprava testů – kdy jsou jednotlivé Test Cases rozepisovány na kroky testů, včetně specifikace potřebných testovacích dat probíhá v době tvorby kódu, kdy je detailní návrh hotov. Příprava test prostředí – probíhá s předstihem již ve fázi Projekce, aby bylo možné připravit do prostředí i potřebná data. Co se bude testovat je známo již po vzniku požadavků na testy a tedy je možné objednat test prostředí. Příprava test dat – probíhá v projektové fázi Konstrukce, po dokončení specifikace potřebných test dat v rámci přípravy testů. Realizace testů – je zahájena po splnění všech precondition (tj. připravenost testů, prostředí, dat, testované aplikace, test týmu atd.). SIT i UAT testy probíhají v iteracích dle podrobného harmonogramu. Vyhodnocení testů probíhá třístupňově: Průběžně při realizaci všech iterací. Po každé iteraci je provedeno vyhodnocení, zda je možné posunout testované řešení do dalšího stádia testů (ze SIT do UAT, z UAT do TAT, z TAT do pilotního provozu). Sumární vyhodnocení testování v rámci hodnocení projektu.

6 Fáze procesů funkčního testování
Testovací cykly Evidence a řešení neshod / chyb Oprava aplikace Fáze plánování a přípravy testů Provádění testů Návrh plánu Vyhodnocování a ukončení testů Tvorba testovacích případů Fáze Vyhodnocení testů Fáze realizace testů Tvorba test prostředí a dat Na tomto snímku máme znázorněno prakticky totéž, co bylo na předchozím, ale již jen z pohledu podprocesů testování a jejich aktivit. V realizaci testů nám přibyla aktivita evidence a řešení neshod a dále oprava aplikace (ta již probíhá na straně vývoje). Opravené funkčnosti jsou retestovány v další iteraci následující po dokončení opravy chyby.

7 2. Plánování a příprava funkčních testů

8 Plánování a příprava funkčních testů
Fáze plánování a přípravy testů : - Tvorba Plánu testů: Definice metodického postupu a naplánování zdrojů Návrh testů (stádia a typy testů) Definice způsobu provedení testování (manuální, automatizované) Definice testovacího prostředí, zahájení přípravy test. prostředí Definice týmu - Vlastní příprava testování: Tvorba testovacích případů (resp. kroků testů) Definice a příprava testovacích dat Příprava testovacího prostředí Z hlediska plánování testů je klíčové nastavení rozsahu a pravidel testování. Toto řeší dokument Plán testů. Z hlediska přípravy testů se pak budeme věnovat především přípravě návrhu testovacích případů a jejich doplnění testovacími kroky.

9 2.1 Plán testů Návrh struktury a rozsahu testů včetně určení způsobu provedení (manuálně, automatizovaně). Definice metodického postupu při akceptačním testování: Organizační struktura testování, stádia testů (SIT, UAT,TAT), řídící orgány Definice odpovědnosti a pravomocí účastníků testování Harmonogram přípravy a realizace akceptačních testů Definice metodiky pro všechny fáze testování (sledované atributy, nastavení procesu provádění testů, evidence neshod/chyb, sledování řešení chyb, způsob vyhodnocení testů). Definice lidských zdrojů - sestavení testovacího týmu. Definice materiálních zdrojů (HW, SW, počet testovacích pracovišť, atd.). Formuláře používaných dokumentů (pokud neexistuje standard). Již před zahájením tvorby testů (testovacích kroků) vzniká dokument Plán testů, který řeší rozsah a testovací strategii testů (rozdělení testovaných oblastí do stádií a typů testů) včetně upřesnění potřeby zdrojů, přičemž vychází ze zpracovaných požadavků na testování (Test Targets). Není-li definována metodika testování, je v dokumentu rovněž stručně uvedena (součástí metodiky jsou i používané formuláře a popis způsobu jejich vyplňování). Po zpracování rozsahu testování je navržena specifikace test prostředí a předána k přípravě. Součástí Plánu testů je i podrobný harmonogram testování. Na závěr je sestaven řešitelský tým pro přípravu a realizaci testů pro daný projekt.

10 2.2 Testovací případy – Test Cases
Návrh a tvorba testovacích případů a testovacích kroků Vytvoření struktury Test Cases, hlavičky testů, namapování na požadavky. Podrobný popis postupu (kroky testů). Konkrétní testovací data (specifikace vstupních dat testu i počáteční stav DB). Očekávané chování (výsledky) aplikace. Průběžná aktualizace harmonogramu přípravy a provádění testů. Vytvoření testovacích sad (posloupnost testovacích případů). Interní ověření testovacích případů a dat, schválení odběratelem. Dokončení přípravy test dat. Dokončení přípravy testovacího prostředí. Jak již bylo v předchozích lekcích řečeno, prvním krokem bývá vytvoření požadavků na testování (TestTargets). K jednotlivým požadavkům pak vznikají testovací případy, které by měly zajistit dostatečné ověření požadavku. Každý testovací případ pak obsahuje jeden nebo více testů, obvykle se vychází z popisu Use Cases. Pro každý test se vytvoří hlavička testu. V rámci přípravy testů jsou pak k jednotlivým hlavičkám testů doplňovány kroky testů, tj. podrobný popis postupu Testera. Souběžně s kroky testů jsou upřesňovány vstupní data a očekávané výsledky za jednotlivé kroky testů. Po dokončení tvorby testů je zpracována sumární specifikace požadovaných testovacích dat a ta je předána k přípravě. Před každou iterací testů je z připravených testů připravena jedna nebo více testovacích sad. Testovací sady jsou připravovány buď pro jednotlivé Testery jako balík, nebo dle funkčních oblastí a jednotlivým testům je pak přidělen konkrétní Tester. Po dokončení přípravy testů následuje dokončení přípravy test dat (obvykle IT analytici ve spolupráci s Test analytiky) a jejich ověření. Protože potřebná data jsou obvykle uložena v DB testovacího prostředí, jde obvykle o poslední přípravný krok .

11 Struktura testovacího případu
Hierarchická úroveň testovacího případu, název testovacího případu, komentář a doplňující údaje Umístění TC v hierarchii funkčností Název testu, zařazení v sadě, komentář a doplňující údaje Hlavička testu Označení (číslo) kroku Postup provedení kroku Očekávané chování aplikace (výsledky) Kroky testu Každý test je přiřazen některému z Test Cases, který může být dále podřízený jinému TC (například – Karty/Kreditní/VISA/Pořízení karty). Test se skládá z hlavičky testu a kroků testu. V hlavičce testu je obvykle uvedeno cíl testu, stručný popis testu, dále může obsahovat precondition , postcondition a testovací data (vstupní i očekávaná). Poslední tři položky jsou volitelné, mohou být kromě hlavičky testu uloženy v krocích testu, nebo v testovacím případu dle toho, jestli jsou platná pouze pro příslušný krok testu, nebo obecněji pro hlavičku testu, nebo ještě obecněji pro celou skupinu TC. Popis testovacích dat, soubory s daty Volitelné: - Preconditions – popis vstupních podmínek - Postconditions – popis výstupních podmínek

12 3. Realizace funkčních testů

13 Realizace funkčních testů
Fáze provádění testů: - Sestavení testovacích sad (dle potřeby daného kola testů). - Inicializace testovacího prostředí. - Provedení testů v iteracích. - Protokol o provedení testu. Fáze evidence a řešení chyb: - Evidence neshod - Řešení chyb - Retesty Je-li připravenost k testům a je nainstalován nový build v testovacím prostředí, je možné zahájit iteraci testů. Před vlastním zahájením iterace je vhodné test prostředí prověřit smoke testem, že je vše v pořádku připravené k provedení testů. Testeři zahájí práci, kdy postupují dle popisu v testech a evidují zjištěné odchylky. Do protokolu testů provádí Tester záznam o provedených testech (OK test, chybný test). Test manager monitoruje množství a závažnost neshod. Každá neshoda je analyzována a podaří-li se identifikovat příčinu neshody, zadá se příslušnému řešiteli k realizaci nápravy (ne vždy musí jít o chybu aplikace, může být chybně provedena posloupnost testů . Po opravě chyby je oprava znovu ověřena retestem. Součástí retestu by mělo být i otestování okolí chyby, ve kterém oprava proběhla, aby se ověřilo, že nebyla opravou „postižena“ původní funkčnost, kde nebyla žádná změna požadována (tzv. regresní test). Stejně tak se regresní test provádí v průběhu poslední iterace pomocí vybraných Test Cases z oblastí, které nebyly požadovanou změnou zasaženy.

14 Inicializace testovacího prostředí
- inicializace prostředí na straně testovaného systému (instalace aplikace, databáze, obslužných programů, nastavení parametrů systému , atd. ) - nastavení prostředí na straně podpůrných testovacích nástrojů (formuláře pro zápis neshod, přístupy do repository projektů pro záznamy, inicializace prostředí pro manuální, případně automatizované testování, atd.) - nastavení výchozích podmínek před vlastním prováděním jednotlivých sad testů (týká se i manuálního testování) Připravenost test prostředí nespočívá pouze v připravenosti testovaného systému ověřené smoke testem, ale je nutné připravit prostředí pro testery, kam budou evidovat záznamy o neshodě a sdílené repozitory s protokoly o provedení testů. V případě použití podpůrného testovacího nástroje je potřeba nastavit přístupy do aplikace a seznámit Testery se zvoleným způsobem vyplňování údajů. Protože se provádí průběžně opravy chyb, je třeba opravené chyby v následující iteraci retestovat a proto je potřeba před zahájením iterace zařadit testy s opravenými chybami do příslušných testovacích sad.

15 3.1 Manuální, provedení Tester provádí jednotlivé kroky dle předem připraveného popisu testovacích případů. Tester kontroluje, zda aktuální chování aplikace odpovídá očekávanému. Tester v průběhu testování zaznamená u každého provedeného testu, proběhl-li ve shodě s očekávaným chováním (protokol o testování). V případě zjištění neshody provede Tester definovaným způsobem záznam neshody. Vedoucí testování vypracuje / vygeneruje protokol o provedených testech. Vlastní provedení testů jsme již popsali v předchozích snímcích, takže jen rekapitulace.

16 3.2 Automatizované, provedení
Na základě připraveného Plánu testů provedou Testeři pomocí podpůrných testovacích nástrojů spuštění automatizovaných testů (nástroje umožňují spouštět automatizované testy i pomocí tzv. „scheduleru“ například v mimopracovní době). Výsledky provedených automatizovaných testů se automaticky zapisují do databáze v rámci repozitory projektu. Tester / Test manager výsledky testů vyhodnotí a provede evidenci zjištěných neshod. Test manager vypracuje / vygeneruje protokol o provedených testech. Automatizované testy jsou často spouštěny v nočních hodinách, především kvůli úspoře času. Automatizovanému testování se budeme věnovat v některé z dalších lekcích, proto uvádíme jen shrnutí, aby byla vidět analogie s manuálními testy.

17 3.3 Fáze evidence a řešení neshod
Evidence neshody - doplnění informací k zaznamenaným chybám (například přidělení závažnosti chyby a priority řešení). Analýza neshody. Přidělení řešitelů a termínů vyřešení jednotlivým chybám. Provedení oprav - nemusí se vždy jednat o chybu aplikace, někdy je potřeba opravit například test, nebo se může jednat o chybu v připravených datech, atd. Regresní testování - obvykle nestačí provést pouze test místa, kde byla chyba detekována, ale je potřeba provést celou sadu testů v okolí vzniklé chyby. Ukončení řešení chyby. Vyhodnocení řešení neshod – průběžně, finálně pro akceptační protokol. Životní cyklus neshody začíná zaevidováním neshody Testerem. Dále Test analytik ve spolupráci s IT analytikem ověří jde-li o chybu aplikace, nebo chybu někde jinde (chybné pořadí testů, chybná data, chybné očekávané výsledky, výpadek sítě apod.), případně doplní další pro opravu potřebné informace a závažnost chyby. Zanalyzované chyby jsou přiděleny řešitelům podle charakteru chyby včetně požadovaného termínu opravy. Neshody, které nebyly vyhodnoceny jako chyby, jsou vráceny (obvykle stav Rejected) s příslušným komentářem. Podobně jsou vraceny chyby s duplicitním záznamem s uvedením odkazu na primární záznam. Řešitel chyby má rovněž právo chybu vrátit, když je přidělena špatnému řešiteli, nebo je špatně zanalyzována (vždy s příslušným komentářem). Opravené chyby jsou předány k nasazení do test prostředí na retesty (stav Fixed). Test manager rozhodne dle charakteru chyby, stavu otestovanosti iterace, zda opravu zařadí do testů probíhající iterace, nebo až do následující. Po retestu je chyba buď uzavřena, nebo s příslušným komentářem znovu otevřena. Test manager průběžně vyhodnocuje stav řešení neshod jak z hlediska poměru počtu chyb zaevidovaných ku opraveným, tak z hlediska trendů nárůstu chyb. Je-li ohrožen finální termín předání aplikace, provádí Test manager s vedením projektu opatření k nápravě stavu. Při předání do produkce pak Test manager vyhodnocuje, kolik identifikovaných chyb zůstalo neopraveno a součástí předávky jsou pak termíny oprav a případné workaroundy pro chyby závažnosti střední, či velká (dáno akceptačními kritérii).

18 Životní cyklus neshody - příklad
Na uvedeném příkladu máme jeden z mnoha možných životních cyklů neshody, příslušná role po zpracování neshody posunuje stav na stav následující, šipky znázorňují zpracování neshody. Například – Vedoucí testování vyhodnotil neshodu jako chybu SW a předává ji do vývoje (vedoucímu vývoje) změnou stavu z New na Open.

19 4. Ukončení funkčních testů

20 Ukončení funkčních testů - vyhodnocení
Počet chyb Po ukončení běhu cyklu funkčních testů vyhodnocujeme jeho průběh zpravidla dle chybovosti systému. Jedním takovým příkladem je statistika uvedená na snímku, která ukazuje závislost závažnosti nalezených neshod v průběhu cyklu testovaní na stavu dané chyby. Každý sloupec grafu tak říká, např. kolik neshod je v kritické závažnosti pro daný stav (otevřená, zavřená neshoda, atd). V daném případě je jasné, že nelze akceptovat řešení do produkce, protože existují chyby závažnosti Kritická v neuzavřeném stavu a tedy aplikace má velké problémy s realizací požadovaného produktu, protože závažnost Kritická značí tzv. Blocker pro příslušnou business funkčnost. Stav řešení chyby

21 Ukončení funkčních testů – akceptace (příklad)
Zadavatel, vývoj, testeři, Provozní podpora Rozsah akceptačního testování Věcná kritéria Kritéria pro vyhodnocení akceptačního testování Vedoucí testování D – Doporučení V – Velká chyba M – Malá chyba K – Kritická chyba Akceptační protokol A v B v C v D Testování Pro akceptaci testovaného produktu musíme brát zřetel na 3 základní kritéria. Musí být definován rozsah testování (ve fázi plánování testování), zadána věcná kritéria pro ověřování jednotlivých funkčností (vznikají ve fázi detailního návrhu) a striktně daná kritéria pro vyhodnocení akceptačních testů (akceptační kritéria). Po provedení cyklu funkčních akceptačních testů vyhotoví vedoucí testování akceptační protokol, kde hodnotí ona kritéria a dává doporučení pro nasazení, nebo nenasazení daného řešení do produkce. Je-li vyhodnocení „C – Použitelné“, je třeba definovat omezení a případné workaroundy pro HelpDesk a školitele, aby uživatelé tato omezení znali a uměli s nimi efektivně pracovat. } Testovací protokol xxxxxxxxxx xxxxxxxx) xxxxxxx xxxxxxxx xxxxxxxxx neshoda - K neshoda - M neshoda - V ... Tester Celkové hodnocení: A – Zcela nefunkční B – Nefunkční C – Použitelné D – Plně funkční

22 Funkční testy – rozhodnutí o nasazení
Testování … nová release Celkové hodnocení: A – Zcela nefunkční B – Nefunkční C – Použitelné D – Plně funkční Provozní podpora Akceptační protokol D Nasazení do provozu Akceptační protokol A nebo Akceptační protokol B nebo C nebo Rozhodnutí o nasazení Change management Systém, změna Řídící komise Jak bylo řečeno, na základě testování vzniká akceptační protokol, který slouží jako milník pro nasazení aplikace do reálného provozu. Zpravidla pokud jsou identifikovány otevřené chyby nejnižší závažnosti, nasazení produktu nic nebání. V případě nevyřešení nejzávažnějších chyb bývá dodávka zamítnuta. V ostatních případech se při nasazení produktu evidují a řeší otevřené chyby a jejich oprava přichází formou nového Service Packu dané aplikace. Pokud dojde k rozhodnutí, že se nasazuje do produkce aplikace s hodnocením „B – Nefunkční“, tak musí oprava následovat velmi brzo po nasazení, takovým opravám se říká Hot - Fix. Problem management NE ANO Nevyřešené chyby Provozní podpora + Nasazení do provozu Evidence problému

23 5. Shrnutí funkčních testů

24 Shrnutí – realizace funkčních testů, 1. iterace (kolo, cyklus)
Kontrola testovacího prostředí Funkční testy manuální Funkční testy automatizované Vyhodnocení Testovací cyklus ve zkratce může vypadat takto. Před zahájením provedeme kontrolu testovacího prostředí z pohledu funkcionality i testovacích dat. Následuje exekuce manuálních, případně automatizovaných funkčních testů a jejich vyhodnocení. S exekucí je úzce svázána evidence neshod, jejich řešení a následné regresní otestování provedených oprav. Náš příklad ukazuje případ, kdy jsou opravy retestovány ještě v rámci dané iterace. Evidence neshody Řešení neshody Regresní testy

25 Příklad přípravy funkčních testů v metodice
Návrh metodiky na přípravu funkčních testů může vypadat i takto. Nesmíme ani zde zapomínat na možnost automatizace, které předchází nutnost ověřit použitý nástroj pro danou aplikaci. Setkat se tak můžete s pojmem „Technologický test“, na jehož základě můžeme, kromě jiných ukazatelů, rozhodovat o využití možnosti automatizace.

26 5. Závěr