Mi a szoftvertesztelés? 100+ ingyenes kézi tesztelési útmutató

A Complete Software Testing Guide with 100+ Manual Testing Tutorials with Testing Definition, Types, Methods, and Process Details:

What is Software Testing?

Software testing is a process of verifying and validating the functionality of an application to find whether it satisfy the specified requirements. Ez az alkalmazás hibáinak megtalálásának folyamata, és annak ellenőrzése, hogy az alkalmazás hol működik a végfelhasználó követelményeinek megfelelően.

Mi a kézi tesztelés?

A kézi tesztelés olyan folyamat, amelynek során a kifejlesztett kódrészlet (szoftver, modul, API, funkció stb.) viselkedését összehasonlítjuk az elvárt viselkedéssel (követelmények).

List of Manual Software Testing Tutorials

Ez a legmélyebb oktatósorozat a szoftvertesztelésről. Nézze át figyelmesen az ebben a sorozatban említett témákat, hogy megtanulja az alapvető és haladó tesztelési technikákat.

Ez az oktatóanyag-sorozat gazdagítja ismereteit, és ezzel együtt fejleszti tesztelési készségeit.

Practice End-to-End Manual Testing Free Training on a Live Project:

Tutorial #1: Basics of Manual Software Testing
Tutorial #2: Live Project introduction
Tutorial #3: Test Scenario Writing
Tutorial #4: Write a Test Plan Document from Scratch
Tutorial #5: Writing Test Cases from SRS Document
Tutorial #6: Tesztvégrehajtás
Tutorial #7: Hibakövetés és tesztaláírás
Tutorial #8: Szoftvertesztelési tanfolyam

Szoftvertesztelési életciklus:

Tutorial #1: STLC

Webtesztelés:

Tutorial #1: Webalkalmazások tesztelése
Tutorial #2: Böngészők közötti tesztelés

Tesztesetek kezelése:

Tutorial #1: Tesztesetek
Tutorial #2: Minta teszteset sablon
Tutorial #3: Követelménykövetési mátrix (RTM)
Tutorial #4: Tesztlefedettség
Tutorial #5: Tesztadatok kezelése

Tesztkezelés:

Tutorial #1: Tesztstratégia
Tutorial #2: Tesztterv sablon
Tutorial #3: Tesztbecslés
Tutorial #4: Tesztmenedzsment eszközök
Tutorial #5: HP ALM Tutorial
Tutorial #6: Jira
Tutorial #7: TestLink Tutorial

Tesztelési technikák:

Tutorial #1: Use Case Testing
Tutorial #2: State Transition testing
Tutorial #3: Boundary Value Analysis
Tutorial #4: Equivalence Partitioning
Tutorial #5: Software testing methodologies
Tutorial #6: Agile Methodology

Defect Management:

Tutorial #1: Bug Life Cycle
Tutorial #2: Bug Reporting
Tutorial #3: Defect Priority
Tutorial #4: Bugzilla Tutorial

Funkcionális tesztelés

Tutorial #1: Bug Life Cycle
Tutorial #2: Bug Reporting
Tutorial #3: Defect Priority
Tutorial #4: Bugzilla Tutorial

Functional Testing

Tutorial #1: Unit Testing
Tutorial #2: Sanity and Smoke Testing
Tutorial #3: Regression Testing
Tutorial #4: System Testing
Tutorial #5: Acceptance Testing
Tutorial #6: Integration Testing
Tutorial #7: UAT User Acceptance Testing

Non-Functional Testing:

Tutorial #1: Non-Functional Testing
Tutorial #2: Performance Testing
Tutorial #3: Security Testing
Tutorial #4: Web Application Security Testing
Tutorial #5: Usability Testing
Tutorial #6: Kompatibilitás tesztelése
Tutorial #7: Telepítés tesztelése
Tutorial #8: Dokumentáció tesztelése

Szoftvertesztelés típusai:

Tutorial #1: A tesztelés típusai
Tutorial #2: Fekete doboz tesztelés
Tutorial #3: Adatbázis tesztelés
Tutorial #4: Végponttól végpontig tartó tesztelés
Tutorial #5: Felderítő tesztelés
Tutorial #6: Inkrementális tesztelés
Tutorial #7: Hozzáférhetőségi tesztelés
Tutorial #8: Negatív tesztelés
Tutorial #9: Backend tesztelés
Tutorial #10: Alfa tesztelés
Tutorial #11: Béta tesztelés
Tutorial #12: Alfa vs. béta tesztelés
Tutorial #13: Gamma tesztelés
Tutorial #14: ERP tesztelés
Tutorial #15: Statikus és dinamikus tesztelés
Tutorial #16: Adhoc tesztelés
Tutorial #17: Lokalizációs és nemzetköziesítési tesztelés
Tutorial #18: Automatizálási tesztelés
Tutorial #19: Fehér dobozos tesztelés

Szoftvertesztelési karrier:

Tutorial #1: A szoftvertesztelési karrier kiválasztása
Tutorial #2: Hogyan szerezzünk QA tesztelési állást – Teljes útmutató
Tutorial #3: Karrierlehetőségek tesztelők számára
Tutorial #4: Non-IT-ből a szoftvertesztelésre váltás
Tutorial #5: Kick Start Your Manual Testing Career
Tutorial #6: Lessons Learned from 10 Years in Testing
Tutorial #7: Survive and Progress in Testing Field

Interview Preparation:

Tutorial #1: QA önéletrajz előkészítése
Tutorial #2: Kézi tesztelési interjú kérdések
Tutorial #3: Automatizálási tesztelési interjú kérdések
Tutorial #4: QA interjú kérdések
Tutorial #5: Kezelj bármilyen állásinterjút
Tutorial #6: Tesztelési állást kapni újoncként

Tesztelés különböző domain alkalmazásokban:

Tutorial #1: Banki alkalmazások tesztelése
Tutorial #2: Egészségügyi alkalmazások tesztelése
Tutorial #3: Payment Gateway Testing
Tutorial #4: Test Point of Sale (POS) System
Tutorial #5: eCommerce Website Testing

Testing QA Certification:

Tutorial #1: Szoftvertesztelési tanúsítási útmutató
Tutorial #2: CSTE tanúsítási útmutató
Tutorial #3: CSQA tanúsítási útmutató
Tutorial #4: ISTQB útmutató
Tutorial #5: ISTQB Advanced

Továbbképzés kézi tesztelés témakörök:

Tutorial #1: Ciklikus komplexitás
Tutorial #2: Migrációs tesztelés
Tutorial #3: Felhő tesztelés
Tutorial #4: ETL tesztelés
Tutorial #5: Szoftvertesztelési mérőszámok
Tutorial #6: Web szolgáltatások

Készüljön fel a kézi tesztelés sorozat 1. bemutatójára !!!!

Bevezetés a manuális szoftvertesztelésbe

A manuális tesztelés egy olyan folyamat, amelyben összehasonlítod egy kifejlesztett kódrészlet (szoftver, modul, API, funkció, stb.) viselkedését az elvárt viselkedéssel (Követelmények).

És honnan fogod tudni, hogy mi az elvárt viselkedés?

A követelményeket alaposan elolvasva vagy meghallgatva és teljesen megértve fogod tudni. Ne feledje, a követelmények teljes megértése nagyon-nagyon fontos.

Gondoljon úgy magára, mint annak a végfelhasználójára, amit tesztelni fog. Ezután már nem vagy kötve, a szoftverkövetelmény-dokumentumhoz vagy az abban szereplő szavakhoz. Ekkor megértheti az alapvető követelményt, és nem csak a rendszer viselkedését tudja ellenőrizni a leírt vagy elmondottakkal szemben, hanem a saját értelmezésével és olyan dolgokkal szemben is, amelyek nincsenek leírva vagy elmondva.

Egyszer előfordulhat, hogy egy követelmény kimarad (hiányos követelmény) vagy implicit követelmény (valami, amit nem kell külön megemlíteni, de teljesíteni kellene), és ezt is tesztelnie kell.

Továbbá, egy követelménynek nem feltétlenül kell dokumentáltnak lennie. Nagyon jól ismerhetjük a szoftver funkcionalitását, vagy akár találgathatjuk is, majd lépésről lépésre tesztelhetjük. Ezt általában ad-hoc tesztelésnek vagy feltáró tesztelésnek nevezzük.

Nézzük meg alaposabban:

Először is, értsük meg a tényt – Akár egy szoftveralkalmazást, akár valami mást (mondjuk egy járművet) hasonlítunk össze, a koncepció ugyanaz marad. A megközelítés, az eszközök és a prioritások különbözhetnek, de az alapvető cél ugyanaz marad, és ez EGYSZERŰ, azaz a tényleges viselkedés összehasonlítása az elvárt viselkedéssel.

Második: – A tesztelés olyan, mint egy hozzáállás vagy gondolkodásmód, amelynek belülről kell jönnie. A készségeket meg lehet tanulni, de csak akkor leszel sikeres tesztelő, ha alapból megvan benned néhány tulajdonság. Amikor azt mondom, hogy a tesztelési készségek tanulhatók, akkor a szoftvertesztelési folyamat köré összpontosított és formális oktatásra gondolok.

De mik a sikeres tesztelő tulajdonságai? Ezekről az alábbi linken olvashatsz:

Itt olvashatod el =>Qualities of Highly Effective Testers

A fenti cikk átolvasása erősen ajánlott, mielőtt folytatnád ezt a bemutatót. Segít összehasonlítani a tulajdonságaidat azokkal, amelyeket a szoftvertesztelői szerepkörben elvárnak.

Akinek nincs ideje végigolvasni a cikket, itt egy összefoglaló:

“A kíváncsiságod, figyelmed, fegyelmed, logikus gondolkodásod, a munka iránti szenvedélyed és a dolgok boncolgatásának képessége sokat számít ahhoz, hogy Pusztító és Sikeres Tesztelő legyél. Nekem bevált, és erősen hiszem, hogy neked is működni fog. Ha már rendelkezel ezekkel a tulajdonságokkal, akkor valóban neked is működnie kell.”

Beszéltünk a szoftvertesztelővé válás alapvető előfeltételeiről. Most pedig értsük meg, miért van és lesz mindig is önálló létjogosultsága a kézi tesztelésnek az automatizálási tesztelés növekedésével vagy anélkül.

Miért van szükség a kézi tesztelésre?

Tudod, mi a legjobb abban, hogy tesztelő vagy, méghozzá kézi tesztelő?

Az a tény, hogy itt nem lehet csak a készségekre hagyatkozni. Meg kell rendelkezned/fejlesztened és fejlesztened a gondolkodási folyamatodat. Ez olyasmi, amit nem igazán lehet megvenni pár dollárért. Neked magadnak kell dolgoznod rajta.

Ki kell alakítanod a kérdezősködés szokását, és minden percben fel kell tenned őket, amikor tesztelsz. Legtöbbször inkább magadnak kell feltenned ezeket a kérdéseket, mint másoknak.

Remélem, hogy végigolvastad az előző részben ajánlott cikket (azaz a rendkívül hatékony tesztelők tulajdonságait). Ha igen, akkor tudod, hogy a tesztelést gondolkodási folyamatnak tekintjük, és az, hogy mennyire leszel sikeres tesztelőként, teljesen attól függ, hogy milyen tulajdonságokkal rendelkezel, mint személyiség.

Lássuk ezt az egyszerű folyamatot:

• Teszel valamit (műveleteket végzel), miközben valamilyen szándékkal megfigyeled (összehasonlítod az elvárhatóval). Most itt jön képbe a megfigyelőképességed és a fegyelmezettséged a dolgok elvégzéséhez.
• Voila! Ez meg mi volt? Észrevettél valamit. Észrevetted, mert tökéletes figyelmet szenteltél az előtted lévő részleteknek. Nem hagyod annyiban, mert kíváncsi vagy. Ez nem volt benne a tervedben, hogy valami váratlan/különös dolog történik, észreveszed és tovább vizsgálod. De most mégis megteszed. Elengedheted a dolgot. De nem szabad elengedned.
• Boldog vagy, rájöttél az okra, a lépésekre és a forgatókönyvre. Most ezt megfelelően és konstruktívan kommunikálod a fejlesztőcsapatnak és a csapatod többi érintettjének. Ezt megteheted valamilyen hibakövető eszközön keresztül vagy szóban, de meg kell győződnöd arról, hogy konstruktívan kommunikálod.
• Oops! Mi van, ha így csinálom? Mi van, ha megfelelő egész számot adok meg bemenetként, de vezető szóközökkel? Mi van, ha… … Mi van, ha… … Mi van, ha? Nem könnyű a vége, nem szabadna könnyen véget érnie. Rengeteg helyzetet & forgatókönyvet fog elképzelni, és valóban kísértést érez majd arra, hogy végre is hajtsa őket.

Az alábbi ábra egy tesztelő életét ábrázolja:

Olvassa el még egyszer a fent említett négy gomolygó pontot. Észrevetted, hogy nagyon rövidre fogtam, de mégis kiemeltem a kézi tesztelői lét leggazdagabb részét? És észrevetted a vastag betűs kiemelést néhány szó felett? Pontosan ezek a legfontosabb tulajdonságok, amelyekre egy kézi tesztelőnek szüksége van.

Most, tényleg azt hiszed, hogy ezek a cselekedetek teljesen helyettesíthetők bármi mással? És a mai forró trend – helyettesíthető-e valaha is automatizálással?

Az SDLC-ben, bármilyen fejlesztési módszertannal, kevés dolog marad mindig állandó. Tesztelőként Ön fogyasztja a követelményeket, átalakítja őket Tesztforgatókönyvekké/Tesztesetekké. Ezután végrehajtja ezeket a teszteseteket, vagy közvetlenül automatizálja őket (tudom, hogy néhány vállalat ezt teszi).

Az automatizálás során a fókusz állandó, azaz a megírt lépések automatizálása.

Visszatérjünk vissza a formális részhez, azaz a kézzel írt tesztesetek végrehajtásához.

Ez esetben nem csak a megírt tesztesetek végrehajtására összpontosít, hanem eközben sok feltáró tesztelést is végez. Emlékszel, hogy kíváncsi vagy? És el fogod képzelni. És nem fogsz tudni ellenállni, valóban azt fogod csinálni, amit elképzeltél.

Az alábbi képen látható, hogyan egyszerűsödik a tesztesetek írása:

Megtöltök egy űrlapot, és végeztem az első mező kitöltésével. Túl lusta vagyok ahhoz, hogy az egérért nyúljak, hogy a fókuszt a következő mezőre helyezzem át. Megnyomom a ‘tab’ billentyűt. Befejeztem a következő és az utolsó mező kitöltését is, most a Submit gombra kell kattintanom, a fókusz még mindig az utolsó mezőn van.

Hoppá, véletlenül megnyomtam az ‘Enter’ billentyűt. Hadd nézzem meg, hogy mi történt. VAGY ott van a submit gomb, duplán kattintok rá. Nem vagyok elégedett. Többször kattintok rá, túl gyorsan.

Észrevetted? Nagyon sok lehetséges felhasználói művelet van, szándékos és nem szándékos is.

Nem fog sikerülni megírni az összes olyan tesztesetet, amely 100%-ban lefedi a tesztelendő alkalmazást. Ennek feltáró módon kell történnie.

Az alkalmazás tesztelése során folyamatosan új teszteseteket fogsz hozzáadni. Ezek olyan hibák tesztesetei lesznek, amelyekkel találkozott, és amelyekre korábban nem írtak teszteseteket. Vagy tesztelés közben valami beindította a gondolatmenetedet, és újabb teszteseteket kaptál, amelyeket szeretnél hozzáadni a teszteset-csomagodhoz és végrehajtani.

Még mindezek után sincs garancia arra, hogy nincsenek rejtett hibák. A nulla hibával rendelkező szoftver egy mítosz. Csak azt lehet megcélozni, hogy a nullához közelítsük, de ez egyszerűen nem történhet meg anélkül, hogy az emberi elme folyamatosan ugyanezt célozná, hasonlóan, de nem kizárólagosan a fentebb látott példafolyamathoz.

Még ma sincs olyan szoftver, amely úgy gondolkodik, mint egy emberi elme, úgy figyel, mint egy emberi szem, úgy kérdez és válaszol, mint egy ember, majd végrehajtja a szándékolt és nem szándékolt műveleteket. Még ha meg is történik ilyesmi, kinek az elméjét, gondolatait és szemét fogja utánozni? A tiédet vagy az enyémet? Mi, emberek, szintén nem vagyunk egyformák, igaz. Mindannyian különbözőek vagyunk. Akkor?

A kézi tesztelés szükségessége, amikor az automatizálás van:

Az automatizált tesztelésnek manapság megvan a maga dicsősége, és az elkövetkező években még több lesz, de egyszerűen nem helyettesítheti a kézi minőségbiztosítási tesztelést (értsd: emberi/felderítő tesztelés).

Biztosan hallotta már: “Nem a tesztelést automatizáljuk, hanem az ellenőrzést automatizáljuk”. Ez a mondat sokat elmond arról, hogy hol tart a manuális QA-tesztelés az automatizált tesztelés körül. Sok nagy név szerte a világon írt és beszélt erről a témáról, ezért nem fogok sokat hangsúlyozni ezen.

Automatizálás nem helyettesítheti az emberi tesztelést, mert:

• Elvárja a futásidejű ítéleteket mindarról, ami a szemünk előtt (tesztelés közben) és néhány esetben a színfalak mögött is történik.
• Ez tiszta és folyamatos megfigyelést igényel.
• Ez kérdezést igényel.
• Elköveteli a vizsgálatot.
• Elköveteli az érvelést.
• Elköveteli a tesztelés során szükséges nem tervezett cselekvéseket.

A tesztelés helyettesíthető egy olyan eszközzel/géppel, amely képes lesz a részleteket befogadni, feldolgozni, cselekvéseket parancsolni és végrehajtani, mint az emberi elme és az ember, és mindezt futási időben és minden lehetséges kontextusban. Ennek az eszköznek megint csak olyannak kell lennie, mint minden lehetséges embernek.

Szóval röviden: az emberi tesztelés nem helyettesíthető. Lehet, hogy néhány év múlva valamelyik hollywoodi sci-fi film közel áll majd hozzá, de a való életben még pár száz évig nem látom, hogy ez bekövetkezne, ezt el tudom képzelni. Nem írom le örökre, mert hiszek a végtelen lehetőségekben.

Egy másik megjegyzés: még ha tényleg meg is történik néhány száz év múlva, az a kép, amit el tudok képzelni, egy ijesztő világ képe az biztos. A Transformers kora. 🙂

=>> Ajánlott olvasmány – A legjobb manuális tesztelési szolgáltató cégek

How Automation Compliments Manual Testing?

Már korábban is mondtam, és most is mondom, hogy az automatizálást nem lehet többé figyelmen kívül hagyni. Abban a világban, ahol a folyamatos integráció, a folyamatos szállítás és a folyamatos telepítés kötelező dolgokká válnak, a folyamatos tesztelés nem ülhet tétlenül. Meg kell találnunk a módját annak, hogy hogyan tegyük ezt.

A legtöbbször az újabb és újabb munkaerő telepítése hosszú távon nem segít ezen a feladaton. Ezért a tesztelőnek (tesztvezetőnek/architektnek/menedzsernek) óvatosan kell eldöntenie, hogy mit automatizáljon, és mit végezzen továbbra is kézzel.

Ez egyre fontosabbá válik, hogy nagyon pontos teszteket/ellenőrzéseket írjunk, hogy azok az eredeti elvárásoktól való eltérés nélkül automatizálhatók legyenek, és a termék visszafejlesztése során a “folyamatos tesztelés” részeként használhatók legyenek.

Megjegyzés: A ‘Folyamatos tesztelés’ kifejezésből származó folyamatos szó a többi, fentebb használt, azonos előtaggal rendelkező kifejezéshez hasonlóan feltételes és logikai hívásoknak van alávetve. A folyamatos ebben az összefüggésben azt jelenti, hogy egyre gyakrabban, gyorsabban, mint tegnap. Míg jelentésében nagyon is jelenthet másodpercenként vagy nanomásodpercenként.

Az emberi tesztelők és az automatizált ellenőrzések (a tesztek pontos lépésekkel, elvárt eredménnyel és az említett teszt kilépési kritériumaival dokumentáltan) tökéletes egyezése nélkül a Folyamatos tesztelés elérése nagyon nehéz, és ez viszont megnehezíti a folyamatos integrációt, a folyamatos szállítást és a folyamatos telepítést.

A teszt kilépési kritériumai kifejezést szándékosan használtam fentebb. Az automatizálási öltönyeink már nem lehetnek hasonlóak a hagyományosakhoz. Biztosítanunk kell, hogy ha hibáznak, akkor gyorsan hibázzanak. És ahhoz, hogy gyorsan sikertelenek legyenek, a kilépési kritériumokat is automatizálni kell.

Példa:

Tegyük fel, hogy van egy blokkoló hiba, amelyben nem tudok bejelentkezni a Facebookra.

A bejelentkezési funkciónak kell lennie az első automatizált ellenőrzésnek, és az automatizálási csomagnak nem szabad lefuttatnia a következő ellenőrzést, ahol a bejelentkezés előfeltétel, mint például egy állapot közzététele. Nagyon jól tudod, hogy ez biztosan nem fog sikerülni. Tehát gyorsabban bukjon meg, gyorsabban tegye közzé az eredményeket, hogy a hiba gyorsabban megoldható legyen.

A következő dolog ismét olyasmi, amit biztosan hallott már korábban – Nem lehet és nem is szabad mindent automatizálni.

Válassza ki azokat a teszteseteket, amelyek automatizálása jelentős előnyökkel jár az emberi tesztelők számára, és jó megtérüléssel jár. Erre vonatkozóan van egy általános szabály, amely szerint meg kell próbálnia automatizálni az összes 1. prioritású tesztesetet, és ha lehetséges, akkor a 2. prioritásúakat is.

Az automatizálás nem könnyen megvalósítható és időigényes, ezért ajánlatos elkerülni az alacsony prioritású esetek automatizálását legalább addig, amíg a magas prioritásúakkal nem végzett. Az automatizálandó esetek kiválasztása és az arra való összpontosítás javítja az alkalmazás minőségét, ha folyamatosan használják és karbantartják.

Következtetés

Remélem, mostanra már megértette, miért és mennyire szükséges a kézi/emberi tesztelés a minőségi termékek előállításához, és hogyan egészíti ki azt az automatizálás.

A kézi minőségbiztosítási tesztelés fontosságának elfogadása és annak ismerete, hogy miért különleges, a legelső lépés a kiváló kézi tesztelővé válás felé.

A következő kézi tesztelési oktatóanyagainkban a kézi tesztelés általános megközelítését, az automatizálással való együttélését és sok más fontos szempontot is tárgyalni fogunk.

Biztos vagyok benne, hogy óriási tudásra fogsz szert tenni a szoftvertesztelésről, ha végigolvasod a sorozat oktatóanyagainak teljes listáját.