Testing: Porovnání verzí

Skočit na navigaci Skočit na vyhledávání
Přidáno 1 939 bajtů ,  3. 10. 2024
Bez shrnutí editace
 
(Není zobrazeno 14 mezilehlých verzí od stejného uživatele.)
Řádek 1: Řádek 1:
Základní informace pro testování aplikací sebrané a přeložené z vybraných výukových serverů.  
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í ==
Řádek 32: Řádek 32:
Definice dat, které jsou nezbytná pro provádění testů.
Definice dat, které jsou nezbytná pro provádění testů.


== Bug priority ==
== 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.
Vhodné pro reportování chyb v aplikaci, aby programátoři věděli, na co se zaměřit nejdříve.


=== Critical ===
=== Critical ===


Bugs that are mission critical to the core functionality of the application and for which there are no workarounds. These bugs absolutely must be fixed before the customer can release the app to the public. Note: A critical bug is extremely rare and should only be used in instances where, if you were the product manager, you would delay the launch of a product due to this one bug.
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.


Examples: Cannot log in, cannot check out or save my shopping cart, an email client that has a bug that prevents users from sending/receiving emails, etc.
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 ===


Bugs that are related to the core functionality of the application, but don’t have to be fixed before product launch. However, these bugs should be fixed in the first available patch or release after launch.
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.  


Examples: A flash demo doesn’t load properly, a bug tracking application that does not allow users to set a bug type/severity, a typo in the large text of the homepage banner, etc.
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 ===


Bugs that do not affect any critical user functionality. Typically, medium severity bugs have workarounds that allow users to accomplish the desired task that the bug may have hindered or the function may still operate but in a degraded fashion.
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ě.  


Examples: A travel site that randomly fails to send email notifications, search results page that displays the right results, but formats incorrectly in Chrome browser etc.
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 ===


Bugs that do not interfere with core functionality and are just annoyances that may or may not ever be fixed.
Problémy, které nezasahují do klíčové funkcionality. Jedná se o problémy, které mohou nebo nemusí být opraveny.  


Examples: A misspelling in the middle of an interior page, text being displayed in the wrong location, the sitemap loads improperly in IE6.
Příklad: překlep na stránce, text se zobrazuje na špatném místě apod.


== Bug report ==
== Bug report ==
Řádek 64: Řádek 69:
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


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.  
[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 ==
== Jak postupovat ==
Řádek 75: Řádek 80:
- Klikat na všechny součásti, zda se na ně dá kliknout a zda dělají to, co od aplikace očekáváme
- 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
- 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


- 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)
== 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 ==
https://www.youtube.com/watch?v=AWX6WvYktwk


== Linky ==
== Linky ==
Řádek 89: Řádek 105:


http://testovanisoftwaru.cz/category/druhy-typy-a-kategorie-testu/
http://testovanisoftwaru.cz/category/druhy-typy-a-kategorie-testu/
https://www.youtube.com/watch?v=MMa4AVdBCZY
14 150

editací

Navigační menu