Testing: Porovnání verzí
Bez shrnutí editace |
|||
Řádek 1: | Řádek 1: | ||
Základní informace pro testování aplikací sebrané z vybraných výukových serverů. | Základní informace pro testování aplikací sebrané z vybraných výukových serverů. | ||
== Manuální testování == | |||
MANUAL TESTING is a type of Software Testing where Testers manually execute test cases without using any automation tools. Manual Testing is the most primitive of all testing types and helps find bugs in the software system. | |||
Any new application must be manually tested before its testing can be automated. Manual Testing requires more effort but is necessary to check automation feasibility. Manual Testing does not require knowledge of any testing tool. One of the Software Testing Fundamental is "100% Automation is not possible". This makes Manual Testing imperative. | |||
The key concept of manual testing is to ensure that the application is error free and it is working in conformance to the specified functional requirements. It also makes sure that reported defects are fixed by developers and re-testing has been performed by testers on the fixed defects. Basically, this testing checks the quality of the system and delivers bug-free product to the customer. | |||
Types of Manual Testing: | |||
In fact, any type of software testing type can be executed both manually as well using an automation tool. | |||
Manual testing can be used in: | |||
Black Box Testing | |||
White Box Testing | |||
Unit Testing | |||
System Testing | |||
Integration Testing | |||
Acceptance Testing | |||
== Testovací plán == | == Testovací plán == | ||
Řádek 54: | Řádek 72: | ||
== 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/ |
Verze z 4. 6. 2020, 07:27
Základní informace pro testování aplikací sebrané z vybraných výukových serverů.
Manuální testování
MANUAL TESTING is a type of Software Testing where Testers manually execute test cases without using any automation tools. Manual Testing is the most primitive of all testing types and helps find bugs in the software system.
Any new application must be manually tested before its testing can be automated. Manual Testing requires more effort but is necessary to check automation feasibility. Manual Testing does not require knowledge of any testing tool. One of the Software Testing Fundamental is "100% Automation is not possible". This makes Manual Testing imperative.
The key concept of manual testing is to ensure that the application is error free and it is working in conformance to the specified functional requirements. It also makes sure that reported defects are fixed by developers and re-testing has been performed by testers on the fixed defects. Basically, this testing checks the quality of the system and delivers bug-free product to the customer.
Types of Manual Testing: In fact, any type of software testing type can be executed both manually as well using an automation tool.
Manual testing can be used in: 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 priority
Vhodné pro reportování chyb v aplikaci, aby programátoři věděli, na co se zaměřit nejdříve.
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.
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.
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.
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.
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.
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.
Low
Bugs that do not interfere with core functionality and are just annoyances that may or may not ever be fixed.
Examples: A misspelling in the middle of an interior page, text being displayed in the wrong location, the sitemap loads improperly in IE6.
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.
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/