Testing
Základní informace pro testování aplikací sebrané a přeložené z vybraných výukových serverů.
Manuální testování
Manuální testování je typ testování, během kterého testeři ručně testují aplikaci bez použití automatizovaných nástrojů. Manuální testování je nejjednodušší ze všech typů testování a napomáhá k odhalení bugů v softwarovém systému.
Každá nová aplikace musí být otestována manuálně před tím než může být testována automaticky. Manuální testování náročnější, ale je potřebné než se započne s jakoukoli automatizací. K manuálnímu testování není potřeba využívat nějakých speciálních nástrojů.
Klíčovým konceptem manuálního testování je zaručení toho, že aplikace je bez chyb a že obsahuje všechny specifikované požadavky na funkcionalitu. Dále je potřeba ověřovat, že opravené defekty jsou opraveny vývojovým týmem. Testeři mají následně za úkol přetestovat aplikaci, zda byly defekty opravdu opraveny a zda oprava nezpůsobila nějaké další chyby.
Při manuálním testování je potřeba, aby tester byl trpělivý, kreativní a aby se na aplikaci díval z pohledu koncového uživatele.
Typy manuálního testování
Různé typy testování mohou být testovány jak automatizovaně, tak manuálně. Z manuálního testování jmenovitě: Black Box Testing, White Box Testing, Unit Testing, System Testing, Integration Testing, Acceptance Testing.
Testovací plán
Plán testování obsahuje především rozsah postupu testování software, definuje druhy a kategorie testů, stanovuje harmonogram prací.
Cíle testování
Definice toho, co očekáváme přesně od provedení testů nad softwarem. Někdy to může být jen ověření nové funkčnosti, jindy naopak kompletní otestování celé aplikace.
Seznam plánovaných oblastí k testování
Přestože by cílem testování při realizaci měly být všechny funkce software, je nutné vytvořit seznam těchto oblastí. K těmto oblastem také navrhuji přiřadit prioritu, která bude určovat, v jakém pořadí budou oblasti otestovány.
Kategorie testů
Kategorie testů, které budou využity během testovacího cyklu. Případně jejich využití v různých úrovních testování
Definice rizik pro testování
Definice hlavních rizik, které mohou znemožnit testování. Jejich podrobný seznam s ohodnocením a návrhem řešení těchto situací je zpracován v analýze rizik
Požadavky na testovací data
Definice dat, které jsou nezbytná pro provádění testů.
Bug x Error
Bug je nevědomá chyba programátora zanesená do aplikace. Nejčastěji k ní dochází při programování, designování aplikace.
Error je programovací chyba. Pokud funkce neodpovídá očekávanému výsledku, pak se jedná o error [chybu].
Bug / Error priority
Vhodné pro reportování chyb v aplikaci, aby programátoři věděli, na co se zaměřit nejdříve.
Critical
Problémy, které jsou součástí klíčové funkcionality aplikace, které nelze v aplikaci nijak obejít. Tyto chyby musí být opraveny před releasem aplikace koncovým uživatelům. Critical chyby jsou extrémně raritní a měly by být takto kategorizovány pouze v případech, kdy by mohlo dojít ke zpoždění releasu aplikace.
Příklad: nelze se do aplikace přihlásit, nelze odeslat objednávku, emailový klient obsahuje chybu, který neumožňuje uživatelům obdržet/odeslat emaily apod.
High
Problémy, které jsou součástí klíčové funkcionality aplikace, ale nemusí být nutně opraveny, než bude projekt nasazen na produkční server. Nicméně tyto chyby musí být opraveny co nejdříve, buď patchem nebo v dalším releasu.
Příklad: flash demo se nenačte správně, nelze vybrat položku ze selectu, překlep v hlavním textu na domovské stránce apod.
Medium
Problémy, které neovlivňují kritickou funkcionalitu. Medium chyby buď lze uživatelsky obejít tak, aby bylo docíleno kýženého výsledku, nebo funkcionalita funguje, ale nepracuje úplně adekvátně.
Příklad: aplikace náhodně neodesílá emailové notifikace, výsledky vyhledávání jsou správné, ale formátují se špatně v daném prohlížeči apod.
Low
Problémy, které nezasahují do klíčové funkcionality. Jedná se o problémy, které mohou nebo nemusí být opraveny.
Příklad: překlep na stránce, text se zobrazuje na špatném místě apod.
Bug report
Dobré informace jsou např. zde: https://www.softwaretestinghelp.com/how-to-write-good-bug-report/
V našem prostředí všeobecně je dobré se zaměřit na část Important Features In Your Bug Report - body Bug Title, Description, Steps to Reproduce
Jak postupovat
V základu jde o to, aby byla aplikace funkční ve všech uživatelských rolích. Ověřit, že nedochází k problémům se zobrazením jednotlivých součástí aplikace, nejsou v aplikaci textové chyby, zda uživatel vidí, co vidět má.
- Přihlásit se ve vybrané uživatelské roli
- Otevřít aplikaci a přihlásit se
- Klikat na všechny součásti, zda se na ně dá kliknout a zda dělají to, co od aplikace očekáváme
- Pokud jsou v aplikaci emailové notifikace, ověřit, že chodí správně na očekávané emailové adresy - v testovacím režimu jsou e-mailové adresy vypsány v textu e-mailů
- nalezené problémy zaznačovat do report sheetu, aby mohl programátor problémy replikovat, je potřeba sepsat krok po kroku jak k nalezenému problému došlo
Test cases
Pokud by došlo k přípravě test casů pro manuální testování, pak tyto testy musí mít několik atributů, které je potřeba dodržet. ID, shrnutí testovacího casu, podmínky pro splnění testu, jednotlivé kroky, předpokládané výsledky, skutečné výsledky, stav (prošlo, neprošlo, chyba), priorita. Testovacím casem se myslí popis činností, které je potřeba vykonat k ověření části testované aplikace, featury nebo funkcionality. Můžeme mít pozitivní, negativní a destruktivní casy. Pozitivní test case znázorní scénář, kdy test má projít. Negativní test case znázorňuje postup, kdy se ověří, že software nedělá to, co nemá. Destruktivní case má být zaměřen na "rozbití" aplikace, např. co se stane když budu opakovaně a rychle klikat na jedno tlačítko "odeslat". Každý test case musí být přesný, pochopitelný pro všechny, musí být specifický, ale ne zbytečně detailní, musí být zopakovatelný, musí být jednoduché provádět úpravy po editaci aplikace.
Aktuálně je část testovacích scénářů v Excelu. Prozatím není využito lepšího, vhodnějšího nástroje, např. https://testcollab.com
Test case x Test scenario
Test case je dokumentování jednotlivých kroků a činností pro provedení testu. Test case se derivuje z testovacího scénáře. Test case obsahuje detailní informace o činnosti, která musí proběhnout pro otestování softwaru. Testovací scénář je popis, který popisuje procedury pro vytvoření test casů. Testovací scénáře vycházejí z požadavků klienta. Testovací scénář je přehled činností, které budou v testu provedeny.
Regresivní testy
Linky
https://www.guru99.com/manual-testing.html
https://www.softwaretestinghelp.com/types-of-software-testing/
https://www.softwaretestinghelp.com/how-a-tester-can-think-as-an-end-user/
http://testovanisoftwaru.cz/manualni-testovani/modely-zivotniho-cyklu-softwaru/
http://testovanisoftwaru.cz/category/druhy-typy-a-kategorie-testu/