13 620
editací
(→Linky) |
značka: editace z Vizuálního editoru |
||
(Není zobrazeno 20 mezilehlých verzí od stejného uživatele.) | |||
Řádek 1: | Řádek 1: | ||
== Bug priority == | 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 === | === 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 === | === 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 === | === 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 === | === 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 == | == Bug report == | ||
Řádek 29: | Řádek 68: | ||
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 | 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 | ||
[https://upolomouc-my.sharepoint.com/:x:/g/personal/babuto00_upol_cz/EVvj-2s3tlhFg0AXEKn5k34BgdcxxhalKkFWe_RBDTuFlw?e=lUNcMg '''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 == | == Linky == | ||
https://www.guru99.com/manual-testing.html | |||
https://www.softwaretestinghelp.com/types-of-software-testing/ | https://www.softwaretestinghelp.com/types-of-software-testing/ | ||
https://www.softwaretestinghelp.com/how-a-tester-can-think-as-an-end-user/ | 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/manualni-testovani/modely-zivotniho-cyklu-softwaru/ | ||
http://testovanisoftwaru.cz/category/druhy-typy-a-kategorie-testu/ | http://testovanisoftwaru.cz/category/druhy-typy-a-kategorie-testu/ |