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 priority
Vhodné pro reportování chyb v aplikaci, aby programátoři věděli, na co se zaměřit nejdříve.
Critical
Bugy, 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 bugs 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 má bug, který neumožňuje uživatelům obdržet/odeslat emaily apod.
High
Bugy, 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
Bugy, které neovlivňují kritickou funkcionalitu. Medium bugy 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
Bugy, 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
Odkaz na report sheet ke stažení. (Do budoucna bych chtěl zavést nějaký nástroj pro správu reportů, případně testovacích scénářů, jelikož pro více než jednoho testera to bude mít mnohem větší význam.)
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
- Dát si vždy pozor na to, zda emailové notifikace jsou v testovacím nebo ostrém režimu (v ostrém režimu jsou emailové notifikace v aplikaci ELF2 kvůli externímu testování personalistkami)
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/