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

Odkaz na report sheet ke stažení.

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

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/