Základy testování

• Často dochází k neúplné specifikaci požadavků ze strany klienta
• Je nutné v průběhu vývoje průběžně ověřovat, zda je navrhované řešení to, které je zákazníkem požadováno

Quality Asurance (QA)

• Je řízený proces ověřování kvality jednotlivých procesů a výstupu realizovaných produktů
• Hlavním principem je metoda DMAIC vycházející z cyklu PDCA a je užívána strategií metodiky SIX SIGMA
• Znamená zajištění kvality, nikoliv její zjištění
• Proces testování funguje v QA jako měřidlo s jehož pomocí se koriguje výstupní produkt

Metoda DMAIC

Fáze definice

• specifikuje cíle a získává informace
• popisuje stav, kterého má být dosaženo
• popisuje způsob užitého měření
• určuje tým řešitelů
• popisuje se proces, který má být zlepšen
• definuje se plán, který má obsahovat jednotlivé činnosti, jež jsou třeba k odstranění problému
• nazýváno define

Fáze měření

• probíhají předem definovaná měření
• odlišují se domněnky od skutečnosti
• provádí se:
  • revize kódu
  • dokumentů
  • vlastní testování funkční aplikace
  • revize užitého procesu
• nazýváno measure

Fáze analýzy výsledků

• analyzuje měření
• zjišťuje skutečný potenciál pro zlepšení
• základem je analýza příčin problémů, nedostatků, nespokojenosti
• zjišťuje se, zda je opravdu řešen původní problém
• nazýváno Analyse

Fáze návrhu zlepšení

• základem zlepšení je odstranění skutečné příčiny
• nastavují se nové parametry procesu a jeho optimalizace
• vše se dělá pro zvýšení spokojenosti zákazníka
• součástí je i zlepšení nákladů, přínosů pro zákazníka
• nazýváno desing improvements

Fáze řízení zlepšeného

• je-li problém úspěšně odstraněn, nebo je dosaženo zlepšení tak se děje následující
• všechny změny se zavádí, standardizují do procesu nebo systému
• přesvědčí se, zda jsou změny řádně uplatněny a zda jsou užity každodenní činností
• stanovuje se období, ve kterém se sleduje dosažení stanovených výsledků
• nazýváno Control

Řízení projektu

Fáze akviziční

• vymezen skoup projektu
• jsou definovány oblasti řešení
• určuje strategie testování
• provádí se odhady pracnosti všech aktivit
• definují se hlavní milníky projektu

Fáze návrh

• probíhá IT analýza
• vzniká dokument IT solution, který schvaluje zadavatel jako potvrzení pochopení požadavků na řešitelské straně
• po schválení IT solution jsou zahájeny práce na detailním návrhu, který slouží jako zadání pro vývojáře
• pro oblast testování vzniká dokument plán testů, kde jsou definovány oblasti, které budou testovány (požadavky na testování)
• je upřesněn odhad pracnosti
• jsou definovány milníky testování

Fáze provedení

• probíhá vlastní vývoj SW řešení
• probíhá příprava testů a testovacího prostředí
• příprava testovacích dat
• realizace jednotlivých stádií testů
• vývojové, SIT, UAT a TAT testy

Fáze ukončení projektu

• řešení je nasazeno, předáváno do rutinního provozu
• je komplementována dokumentace
• akceptační protokoly
• je vypracováno závěrečné hodnocení projektu

Diagram životního cyklu tvorby SW

• Je nazýván V-Diagram
• Znázorňuje, co se ve které fázi projektu testuje a proti jaké dokumentaci
• Vývojové testy probíhají proti detailnímu návrhu
• Testy komponent probíhají proti IT solution
• Testování systému probíhá formou integračních testů proti systémovým požadavkům
• Akceptační testování probíhá proti uživatelským požadavkům, kde jsou formulovány produkty a jejich vlastnosti
• Pokud dojde k vynechání jednoho ze vstupů, nemůže být testování úspěšné
• Chybějící podklady je nutné sehnat jinak, třeba konzultací se zadavatelem, což není vždy možné

Diagram nákladů na opravu chyb

Ukazuje náklady na opravu chyby v jednotlivých částech vývoje

Testování

Validace

• Probíhá v různých fázích projektu
• Účastní se jí různé role pracující na projektu
• Ověření, že uživatelské požadavky odpovídají potřebám uživatele je prováděno IT analytikem ve spolupráci s View analytikem
• Vyjasňují se jednotlivé pojmy a způsob práce uživatele a možnosti užité technologie
• Technologie je omezujícím faktem některých změnových řízení
• Provádí-li se ověřování je možné práce ukončit dříve, nežli se projekt naplno rozběhne a případné technologické limity budou zjištěny později
• Je nutno ověřit, že kvalitativní požadavky odpovídají způsobu práce koncového uživatele a současně umožňují splnit uživatelské požadavky v plném rozsahu jak z hlediska funkčnosti, tak z hlediska výkonosti systému
• Ve fázi vniku návrhu řešení je nutné se soustředit i na to, zda je návrh schopen kvalitativní požadavky naplnit, nebo je nutné je zrevidovat, či pozměnit navrhované řešení
• Posledním krokem je otestování, zda jsou splněny uživatelské požadavky tak, jak byly schváleny (provádí tester ve stádiu SIT testů)

Verifikace

• Je finální přejímka zboží zákazníkem
• Ověřuje, že je možné produkty pomocí SW řešení realizovat
• Provádí UAT tester (zadavatel) v rámci stádia UAT testů
• V případě pilotního provozu přímo koncový uživatel

Důležité!

• Testování znamená měřit
• Je nutné znát jednotlivé měřitelné požadavky a jednoznačná kritéria jejich naplnění
• Je nutné ověření již ve fázi definice uživatelských požadavků
• Netestovatelné požadavky jsou ignorovány, řešení nemusí splňovat představy uživatele
• Je nutná revize neúplných požadavků => zpoždění projektu
• Kritéria pro schválení řešení se nazývají akceptační
• Akceptační kritéria by měla být nadefinována zároveň se zadáním požadavků
• Typická akceptační kritéria jsou: 0 chyb závažnosti kritická nebo velká, maximálně 5 chyb závažnosti střední s definovaným workraundem a určeným termínem jejich odstranění, maximálně 15 chyb závažnosti malá s určeným termínem odstranění, odezvy kritických operací budou do 3s, nekritické operace s odezvou maximálně 15s.
• Musí být jednoznačně definovány typy závažnosti s uvedením příkladů
• Musí být definováno, co je kritická a co je nekritická operace
• Je nutné si uvědomit, že testováním je možné chyby odhalovat, ale ne garantovat bezchybnost aplikace
• Akceptační kritéria připouštějí nasazení řešení s identifikovanými chybami
• Akceptační kritéria:
  • Ukazatel, který měříme
  • Metriku, která bude užita
  • Hodnotu, která je akceptační hladinou
• Častý je požadavek: systém poskytne uživateli přiměřenou odezvu na běžném internetovém připojení a to i v situaci, kdy pracuje v systému většina uživatelů

Typy testů a základní pojmy

• Prvním krokem ke sjednocení bylo definování metody FURPS (dělí typy testů dle jasně daných hledisek)

Dělení typů

• Dle stádia (SIT, AUT, TAT)
• Dle znalosti kódu (white-box, black-box)
• Dle způsobu provedení (manuální, automatizované)
• Dle potřeby běžící aplikace (statické, dynamické)
• Dle účelu (funkční, zátěžové, instalační, smoke…)
• Dle podmnožin (funkční – UNIT, assembly, integrační, smoke)

Hlediska FURPS

• Funkcionality (funkčnost)
• Usability (užitečnost)
• Reliability (spolehlivost)
• Performance (výkonnost)
• Supportability (rozšiřitelnost)

Metoda FURPS

• Určuje způsob testování
• Lez užít jen některé ze skupin testů, ale je nutné vyhodnotit rizika s tím spojená

Typy testů v časové ose projektu

• Zátěžový a penetrační test má smysl realizovat až v době končících UAT testů, protože mají ověřovat až finální stav řešení před předáním do funkčního prostředí a jejich výsledky bývají součástí akceptačního protokolu

Stádium testů

• Rozdělení testů dle realizace v časové ose v rámci životního cyklu vývoje SW řešení a v rámci procesu testování

White-box testy

• Jsou vývojové testy ověřující správnost funkčnosti jednotlivých algoritmů a metod, pomocí automatizovaných testů
• Je k dispozici příslušná dokumentace, binární a zdrojový kód testované aplikace
• Provádí je mimo jiné UNIT testy

Black-box testy

• Je základním testem zdrojového kódu
• Účelem je ověřit správnost datových typů a logiky kódu
• Testování probíhá bez znalosti vnitřní datové a programové struktury
• Známé jsou vstupy a očekávané výstupy

UNIT testy

• Testování malých nezávislých částí kódu, funkčností jednotlivých dílčích algoritmů, v rámci některého z vývojových nástrojů
• Typickým znakem je, že nedochází k zápisu do DB

Assembly testy

• Navazují na UNIT testy
• Jsou prováděny vývojáři
• Ověřují spolupráci dílů otestovaných UNIT testy
• Jsou kombinací UNIT a black-box testů
• Tester zná částečně strukturu kódu

Funkční testy

• Ověřují správnost dílčích výstupů na základě připravených vstupů do jednotlivých modulů
• Patří sem i UNIT testy
• Užívá se především v SIT testech

Integrační testy

• Jde o manuální funkční testy
• Ověřuje schopnost komunikace metod a modulů
• Užívá se především v SIT testech
• U rozsáhlých systémů jsou nutnou součástí akceptačního testování

End to end testy

• Jsou manuální integrační testy ověřující celý byznys proces vybraného produktu
• Neověřuje dílčí funkčnost, ale klade důraz na realizovatelnost produktu v celém životním cyklu
• Užívá se především v UAT testech

Výkonnostní testy

• Měří výkonnost systému z pohledu koncového uživatele
• Slouží k ladění systému, nebo ke zjištění výkonnostních limitů
• Dělí se dle cíle testu
• Back mark, zátěžový, akceptační, low test, test výkonnostního profilu, ladění výkonu…

Bezpečnostní testy

• Může mít zastoupení již při revizi návrhu řešení
• Ověřuje architekturu
• Pomocí rewyou kódu hledá napadnutelná místa kódu
• Ověřuje loginy
• Významnou formou jsou penetrační testy, kde se tester pokouší prolomit ochranné mechanismy
• Jsou jak manuální, tak automatizované

Regresní testy

• Zjišťují, zda nová verze aplikace nemá vliv na její původní funkcionalitu
• Užívají se při ověřování opravy chyb, kde je ověřeno okolí chyby, kam oprava neměla zasáhnout

Instalační testy

• Ověřují správnost dokumentace v návaznosti na instalační postup
• Ověřují správnou funkčnosti instalačních postupů

Technologické testy

• Slouží k ověření použitelnosti testovacího nástroje na danou aplikaci
• Ověřují kompatibilitu použité technologie ve stávající SW a HW konfiguraci
• Ověřují také možnost užití podprůměrného testovacího nástroje (WinRunner)

Smoke testy

• Je modifikací funkčního testu, kdy je v krátké době přezkoušena základní funkčnost
• Užívá se k ověření správnosti instalace SW

Funkční specifikace

• Je komplexní analytické zadání požadavků, nebo skupiny požadavků
• Jde o množinu analytických dokumentů, algoritmů a diagramů, které slouží jako zadání pro programátory
• Pro podporu analytické práce existují nástroje využívající UML nástroje

Testovací skript

• Obsahuje sekvenci činností testera při testování aplikace zkonvertovanou do formy programového kódu
• Používá se pro automatizované funkční testy
• Pro automatizované testy existují nástroje, které usnadňují konverzi do programového kódu, umožňují nahrání testovacího skriptu a jeho další úpravy
• Často je pojem využíván i pro manuální testy

Zátěžový skript

• Je obdobou testovacího skriptu v úpravě pro paralelní spouštění více uživatelů na jednom stroji
• Existují podpůrné nástroje tvorby

RUP

• Je obecná komplexní metodika vývoje SW
• Slouží jako podklad pro nadefinování postupu testů s ohledem na stávající firemní zvyklosti

Role v testování

• RUP přiděluje odpovídajícím společným aktivitám určitou roli
• Test manažer je kompletně odpovědný za proces testování
• Test analyst provádí test analýzu a určuje oblasti testování, monitoruje naplnění strategie testování a podílí se na vyhodnocení jednotlivých iterací
• Test designer je odpovědný za určení všech detailů jednotlivých testů, které se váží k jednotlivým test cases, určuje strategii tesů, zajišťuje všechny podklady pro úspěšnou implementaci všech částí testování
• Test deployment exekutiv je odpovědný za implementaci, nasazení, vykonání a vyhodnocení veškerých částí testů dle vytvořených návrhů a specifikacích testů, koordinuje přípravu test prostředí; nemá rozhodovací pravomoc jen pravomoc pro koordinaci podřízených rolí
• Test implementer je odpovědný za implementaci svěřených částí testů; připravuje testovací sady
• Test executor je odpovědný za vykonávání přidělené sady testů a protokolování výsledků z přidělené sady
• Test auditor kontroluje správnost testovacích postupů, dodržování metodik, zásad a standardů
• V praxi dochází ke kumulaci rolí