User:CzechHero/UTBFAI/A2TSO

= Pojmy =
 * Konfirmační test - bug je opravený
 * Regresní test - funguje vše kolem tak jak má
 * Black box - testování bez přístupu ke kódu, tedy pouze vizualizace pomocí vstupů a výstupů
 * White box - testování s přístupem ke kódu

= Syllabus =
 * istqb.org
 * castb.org
 * download -> foundation syllabus

= Sedm principů testování =
 * Testování ukazuje přítomnost defektů
 * Ale nedokazuje, že zde žádné defekty nejsou
 * Snižuje pravděpodobnost nenalezení defektů
 * Pokud nejsou nalezeny žádné defekty, není to důkaz správnosti
 * Úplné testování je nemožné
 * Nelze otestovat vše, tzn. všechny kombinace
 * Včasné testování
 * Testovací aktivity by měly začít co nejdříve
 * Důvodem je cena opravy
 * Shlukování defektů
 * Nalezená chyba znamená vyšší pravděpodobnost více chyb ve stejné oblasti
 * Oblast (cluster) = komponenta, třída, část kódu
 * Pesticidní paradox
 * Management test casů, změna
 * Testování je závislé na kontextu
 * Testuje se různě v různých souvislostech
 * Např. budeme testovat jinak e-shop a software jaderné elektrárny
 * Falešná představa o neexistenci omylů
 * Testování zvyšuje pravděpodobnost nalezení a odstranění defektů
 * I dobré testování nikdy nezachrání (nepoužitelný systém, nesplněné požadavky, nenaplněné očekávání uživatelů)

Checkpoint
Najít defekty, prevence defektů, zvýšit spolehlivost Nikdy Systém splňuje požadavky uživatele
 * 1) Co může způsobit defekt softwaru?
 * 2) Jak spolu souvisí pojmy defekt, omyl, chyba, bug a selhání?
 * 3) Jaké jsou cíle testování
 * 1) Kdy přestat testovat?
 * 1) Co je cílem akceptačního testování?
 * 1) Popiš 7 principů testování

= Základní testovací proces =

Plánování a řízení testování

 * Naplánovat si to, aby jsme se dostali k cíli
 * Testovací prostředí
 * Řízení - tak jak to bylo naplánování
 * Plánování testů
 * Definování cílů testování
 * Specifikace testovacích činností
 * Řízení testování
 * Porovnání aktuálního postupu vůči plánu
 * Reportování stavu
 * Cílem se dostat do cíle a naplnit mission

Analýza a návrh testování

 * Hlavní úkoly
 * Identifikace a prioritizace testovacích podmínek
 * Návrh a prioritizace obecných testovacích případů
 * Identifikace testovacích dat
 * Návrh nastavení testovacího prostředí
 * Identifikace požadované infrastruktury a nástrojů
 * Tvorba trasovatelnosti (traceability)
 * Cíl
 * Transformace cílů a úkolů do testovacích podmínek respektive testovacích případů

Implementace a vykonání testů

 * Hlavní úkoly
 * Implementace testovacích případů
 * Tvorba testových procedur
 * Tvorba testovacích dat
 * Psaní automatizovaných testovacích skriptů
 * Vykonání testovacích procedur
 * Zaznamenání výstupů z provedených testů
 * Porovnávání aktuálních výsledků s těmi očekávanými
 * Reportování nesrovalostí a jejich analýza
 * Cíle
 * Příprava testovacích procedur a skriptů
 * Nastavení prostředí
 * Provedení testů

=== Vyhodnocení výstupních kritérii
 * Hlavní úkoly
 * Vyhodnocení, co jsme dělali během testování
 * Kontrola protokolů o testech vůči výstupním kritériím
 * Zhodnocení, je-li potřeba více testů
 * Sepsání sumárních reportů pro zainteresované osoby
 * Cíl
 * Poskytnutí nezávislého pohledu

Aktivity uzavření testování

 * Hlavní úkoly
 * Kontrola, které plánované dodávky byly dodány
 * Uzavření záznamů o incidentech nebo nahlášení záznamu o změně
 * Dokumentace akceptace systémů
 * Finalizace a archivace testwaru
 * předání testwaru organizaci zajišťující provoz (podporu)
 * Analýza získaných znalostí a informací ke zlepšení
 * Cíl
 * Konsolidace zkušeností, testwaru a faktů

= Ladění a testování =

Ladění (debugging)

 * Hledá a odstraňuje defekty

Testování

 * Hledá a odstraňuje selhání

= Proč mít testery v projektu? =
 * Přístup používaný při testování je odlišný od přístupu použitém při vývoji softwaru
 * Vývojář
 * Tvořivá, pozitivní práce
 * Řeší problémy v průběhu procesu vývoje
 * Někdy přiliš velká vazba s výsledky své práce
 * Nemusí si přiznat, že udělal chybu
 * Tester
 * "Ničivá," "negativní" práce
 * Snaží se najít co nejvíce selhání
 * Nemá citovou vazbu k projektu


 * Výhody
 * Nezávislost, znalost testovacích metodik, zkušenosti, cena
 * Nezávislost - hlavní výhoda (objektivnost
 * Nevýhody
 * Nevidí kód
 * Nepoznají produkt tak dobře jako vývojáři

= Psychologické aspekty =
 * Nacházení selhání během testování může být vnímáno jako kritika
 * Vůči produktu
 * Vůči autorovi
 * Jako destruktivní činnost
 * Základní pravidlo - vždy buďte konstruktivní a empatičtí

= Jak začít s testováním =

Nemám nic

 * pak použiji tzv. průzkumné testování
 * mohu se odrazit od podobných chyb, své zkušenosti, podobných produktů
 * výrazně se upltňuje při agilním testování

Mám požadavky, co má software dělat

 * mohou být formální (dokument)
 * neformální (výsledek diskse, help files, screenshoty konkurenčního produktu)

= Požadavek =
 * requirement, user story
 * S M A R T
 * S - Specific - požadavek musí být specifický a dobře napsaný
 * M - Measurable - musí to být měřitelné
 * A - Achievable - musí to být realizovatelné
 * R - Relevant - požadavek musí mít nějaký základ, něco splňovat, mít význam
 * T - Testable - musí to být testovatelné (máme k tomu prostředky, jsme toho schopni?)

= 3. PŘEDNÁŠKA - CHYBÍ =

= Revize kódu = == Statické / Dynamické testování =

Dynamické testování

 * vyžaduje mít spuštěný testovaný produkt
 * lze dynamicky testovat něco jiného než software?

Statické testování

 * předpokládá se v čase neměnné chování
 * prováděno typicky před dynamickým testováním
 * oprava nalezených defektů je méně nákladná
 * nachází příčiny selhání nebo přímo defekty
 * statické techniky
 * revize
 * statická analýza

Co lze zkoumat statickým testováním?

 * programový kód
 * specifikace návrhu, specifikace požadavků
 * testovací případy a procedury
 * testovací skripty
 * manuály a uživatelské příručky
 * webové stránky

Proč používáme statické techniky?
méně defektů v dalších úrovních lepší porozumění kódu a dokumentaci lepší udržovatelnost kódu a návrhu
 * včasná detekce defektů
 * apod

Typické defekty

 * odchylky vůči standardům
 * defekty v požadavcích
 * defekty v návrhu
 * nedostatečná udržovatelnost
 * nesprávné specifikace rozhraní

Aktivity při statické testování

 * 1) Plánování a definování vstupních a výstupních kritérií
 * 2) Kick-off
 * 3) Individuální příprava
 * 4) Provedení, vyhodnocení, zaznamenání výsledků
 * 5) Přepracování
 * 6) Navazující kroky s kontrolou výstupních kritérií

Revize - role

 * Manažer - rozhoduje o vykonání revizí
 * Moderátor - vede revizi dokumentů
 * Autor - osoba s hlavní odpovědností za revidované dokumenty
 * Revidující - jednotlivec se specifickou technickou nebo obchodní znalostí, identifikuje a popisuje nálezy
 * Zapisovatel - dokumentuje veškeré body

Typy revizí

 * Neformální revize -> Walkthrough -> Technická revize -> Inspekce

Neformální revize

 * Žádný formální proces
 * Výsledky mohou, ale nemusí být dokumentovány
 * Revize kolegou (peer review) nebo technickým vedoucím
 * Účel - levný způsob jak získat nějaký přínos

Walkthrough

 * Schůzka vedená autorem
 * Forma
 * scénáře
 * zkoušky "nanečisto"
 * participace skupiny kolegů
 * Volitelně
 * příprava reportu revize zahrnující seznam nálezů
 * zapisovatel
 * Může být neformální až velmi formální
 * Účely
 * učení
 * získání porozuměění
 * nalezení defektů

Technická revize

 * Schůzka vedená zaškoleným moderátorem (ne autorem)
 * Dokummentovaný proces odhalování defektů
 * Příprava revidujících před schůzkou
 * Volitelné použití kontrolních seznamů
 * Příprava revizního reportu
 * Může být neformální až velmi formální
 * Účely
 * Diskuse
 * Rozhodování
 * Vyhodnocování alternativ
 * Nacházení defektů
 * Prověřování souladu se specifikacemi, plány, směrnicemi a standardy

Inspekce

 * Vedeno moderátorem
 * Definované role
 * Formální proces založený na pravidlech a kontrolních seznamech
 * Zahrnuje sběr metrik
 * Specifikovaná vstupní a výstupní kritéria pro akceptaci
 * Příprava před schůzkou
 * Report zahrnující seznam zjištění
 * Účel
 * nacházení defektů

Shrnutí

 * obr. 2

Faktory úspěchu

 * Revize má jasně předdefinované cíle
 * Jsou zahrnuti vhodní lidé
 * Nalezené defekty jsou komunikovány objektivně a přijímaný pozitivně
 * Lidské spory a psychologické aspekty jsou zvládnuty
 * Výsledek není použit k hodnocení zúčastněných
 * Jsou použity vhodné techniky k dosažení cílů
 * Používají se kontrolní seznamy nebo role ke zvýšení efektivity
 * Účastníci jsou proškolení
 * Proces revize je podporován managerem

Statická analýza kódu

 * Hledání defektů ve zdrojovém kódu softwaru
 * Obvykle pomocí nástrojů
 * Nalézá spíše defekty, které
 * je těžké nebo nemožné najít pomocí dynamického testování
 * se dají dobře automazitovat
 * Analýza
 * programového kódu (řídící tok, datový tok)
 * výstupů (HTML, XML)

Statická analýza kódu - proč?

 * Včasná detekce defektů
 * Včasné varování o podezřelých aspektech (např. vysoká míra složitosti)
 * Identifikace obtížně odhalitelných defektů (nástroje)
 * Detekce závislosti a nekonzistencí
 * Prevence defektů

Typické defekty

 * Odkaz na proměnnou bez definované hodnoty
 * Nekonzistentní rozhraní mezi moduly a komponentami
 * Nepoužité proměnné
 * Nedosažitelný (dead) kód
 * Chybějící a chybná logika
 * Porušení standardů programování
 * Bezpečnostní nedostatky
 * Porušení syntaxe kódu a softwarových modelů

Nástroje

 * Běžně používány vývojáři a návrháři
 * Mohou produkovat velké množství varovných hlášení
 * Kompilátory - pomoc pro statickou analýzu (včetně výpočtu metrik)
 * Speciální nástroje
 * CodeItRight
 * Sonar
 * Lint
 * Checkstyle
 * Debuggery v IDE

Opakování - úrovně testování

 * 1) Testování komponent (unit)
 * 2) Integrační testování
 * 3) Systémové testování
 * 4) Akceptační testování

Automatizace testování

 * jedna z hlavních náplní testera v agilním projektu
 * v agilním projektu je klíčová
 * proč?
 * vysoké tzv. riziko regrese
 * časté změny
 * neustále se zvyšující objem testování díky dodávkám v iteracích

Jak simulovat uživatele

 * 1) Capture-and-replay
 * funguje podobně jako záznam makra v MS Excel
 * stisknete nahrávání
 * provádíte to, co byste prováděli při manuálním testu
 * ukončíte nahrávání
 * máte možnost přehrát celou interakci
 * vhodné pro velmi jednoduché testy (login, akceptace cookies, apod.)
 * není možno propojit s daty
 * není možno strukturovat
 * 1) Přímé psaní kódu

Co automatizovat

 * 1) Happy path (thin slice)
 * 2) WWCH (what worst can happen)
 * 3) Co se bude často opakovat
 * deployment do testovacího prostředí
 * obnova databáze
 * čištění databáze
 * report z testů
 * metriky
 * 1) Co má nejvyšší hodnotu rizika

TDD/ATDD/BDD
Tedy:
 * TDD = test drive development
 * ATDD = acceptance tests driven development
 * BDD = behavior driven development
 * analysis -> create a test -> run the test (to fail) -> write the code -> run the test (to pass) -> refractor -> re-run the test
 * Přidej test
 * nadefinuj koncept
 * zaměř se na malý kousek kódu
 * Pusť test
 * poprvé musí spadnout
 * Napiš kód
 * tak, aby test prošel
 * Pusť test
 * ověř, že test prochází
 * Proveď refractoring (pokud je to nutné)

=== Techniky návrhu testů
 * 1) Techniky návrhu testů černé skříňky
 * založené na specifikaci
 * tzv. modelové
 * 1) Techniky návrhu testů bílé skříňky
 * založené na struktuře
 * tzv. strukturální
 * 1) Techniky založené na zkušenostech
 * využívány znalosti a zkušenosti lidí
 * o software, o oblasti (doméně), o vývojářích, o prostředí, o možných defektech a jejich šíření, o kvalitách webových prohlížečů
 * 1. odhadování omylů (error guessing)
 * tester odhaduje nejčastější omyly v aplikaci
 * 2. útok na chyby (fault attack)
 * Systematický a strukturoavný přístup k odhalování chyb
 * testy jsou navrženy k útoku na chyby podle seznamu
 * 3. průzkumné testování (exploratory testing)
 * opak skriptovaných testů
 * tester může dělat všechny činnosti kdykoliv
 * flexibilní

CI / CD

 * Continuous integration
 * Bamboo
 * Cruise Control
 * Jenkins
 * Hudson
 * IBM Rational Team Concert
 * TeamCity
 * Continuous deployment
 * Graddle
 * Maven
 * Nolio Zero Touch Deployment
 * Jenkins