Co je testování softwaru? 100+ bezplatných návodů na ruční testování

Kompletní průvodce testováním softwaru s více než 100 návody na ruční testování s definicí testování, typy, metodami a podrobnostmi o procesu:

Co je testování softwaru?

Testování softwaru je proces ověřování a validace funkčnosti aplikace s cílem zjistit, zda splňuje stanovené požadavky. Je to proces hledání chyb v aplikaci a kontroly, kde aplikace funguje v souladu s požadavky koncového uživatele.

Co je to manuální testování?

Manuální testování je proces, při kterém porovnáváte chování vytvořeného kusu kódu (softwaru, modulu, rozhraní API, funkce atd.) s očekávaným chováním (požadavky).

Seznam výukových materiálů o manuálním testování softwaru

Toto je nejpodrobnější série výukových materiálů o testování softwaru. Pečlivě si projděte témata uvedená v této sérii a naučte se základní i pokročilé techniky testování.

Tato série výukových kurzů obohatí vaše znalosti a následně zvýší vaše dovednosti v oblasti testování. Test Execution
Tutorial #7: Bug Tracking and Test Sign off
Tutorial #8: Kurz testování softwaru

Životní cyklus testování softwaru:

Tutorial #1: STLC

Web Testing:

Tutoriál #1: Testování webových aplikací
Tutoriál #2: Testování napříč prohlížeči

Řízení testovacích případů:

Tutoriál #1: Testovací případy
Tutoriál #2: Vzorová šablona testovacího případu
Tutoriál #3: Matice sledovatelnosti požadavků (RTM)
Tutoriál #4: Pokrytí testů
Tutoriál #5: Správa testovacích dat

Řízení testů:

Tutoriál #1: Strategie testování
Tutoriál #2: Šablona plánu testování
Tutoriál #3: Odhadování testů
Tutoriál #4: Nástroje pro správu testování
Tutoriál #5: Výukový kurz HP ALM
Tutoriál #6: Jira
Tutoriál #7: TestLink Tutoriál

Testovací techniky:

Tutoriál #1: Testování případů užití
Tutoriál #2: Testování přechodů mezi stavy
Tutoriál #3: Analýza hraničních hodnot
Tutoriál #4: Rozdělení ekvivalence
Tutoriál #5: Metodologie testování softwaru
Tutoriál #6: Agilní metodologie

Řízení vad:

Tutoriál #1: Životní cyklus chyby
Tutoriál #2: Hlášení chyb
Tutoriál #3: Priorita defektů
Tutoriál #4: Výukový program Bugzilla

Funkční testování

Tutoriál #1: Unit Testing
Tutoriál #2: Sanity a Smoke Testing
Tutoriál #3: Regresní testování
Tutoriál #4: Systémové testování
Tutoriál #5: Akceptační testování
Tutoriál #6: Integrační testování
Tutoriál #7: Uživatelské akceptační testování UAT

Nefunkční testování:

Tutoriál #1: Nefunkční testování
Tutoriál #2: Testování výkonnosti
Tutoriál #3: Bezpečnostní testování
Tutoriál #4: Testování bezpečnosti webových aplikací
Tutoriál #5: Testování použitelnosti
Tutoriál #6: Testování kompatibility
Tutoriál #7: Testování instalace
Tutoriál #8: Testování dokumentace

Typy testování softwaru:

Tutoriál #1: Typy testování
Tutoriál #2: Testování softwaru: Testování černé skříňky
Tutoriál #3: Testování databází
Tutoriál #4: Testování od konce ke konci
Tutoriál #5: Průzkumné testování
Tutoriál #6: Inkrementální testování
Tutoriál #7: Testování přístupnosti
Tutoriál #8: Negativní testování
Tutoriál #9: Backend testování
Tutoriál #10: Alfa testování
Tutoriál #11: Beta testování
Tutoriál #12: Testování alfa vs. testování beta
Tutoriál #13: Testování gama
Tutoriál #14: Testování ERP
Tutoriál #15: Statické a dynamické testování
Tutoriál #16: Adhoc testování
Tutoriál #17: Testování lokalizace a internacionalizace
Tutoriál #18: Automatické testování
Tutoriál #19: Testování bílé skříňky

Kariéra testera softwaru:

Tutoriál #1: Výběr kariéry testera softwaru
Tutoriál #2: Jak získat práci QA testera – kompletní průvodce
Tutoriál #3: Možnosti kariéry testera
Tutoriál #4: Příprava životopisu QA
Tutoriál #2: Otázky na pohovor pro manuální testování
Tutoriál #3: Otázky na pohovor pro automatizační testování
Tutoriál #4: Otázky na pohovor pro QA
Tutoriál #5: Zvládněte jakýkoli pracovní pohovor
Tutoriál #6: Získejte práci v oblasti testování jako nováček

Testování aplikací v různých oblastech:

Tutoriál #1: Testování bankovních aplikací
Tutoriál #2: Testování zdravotnických aplikací
Tutoriál #3: Testování platebních bran
Tutoriál #4: Testování pokladních systémů
Tutoriál #5: Testování webových stránek elektronického obchodu

Testování certifikace QA:

Tutoriál #1: Průvodce certifikací testování softwaru
Tutoriál #2: Průvodce certifikací CSTE
Tutoriál #3: Průvodce certifikací CSQA
Tutoriál #4: Průvodce certifikací ISTQB
Tutoriál #5: ISTQB Advanced

Témata pokročilého manuálního testování:

Tutoriál #1: Cyklomatická složitost
Tutoriál #2: Migrační testování
Tutoriál #3: Cloudové testování
Tutoriál #4: ETL testování
Tutoriál #5: Metriky testování softwaru
Tutoriál #6: Webové služby

Připravte se na 1. tutoriál z této série o manuálním testování !!!!

Úvod do manuálního testování softwaru

Manuální testování je proces, při kterém porovnáváte chování vytvořeného kusu kódu (softwaru, modulu, API, funkce atd.) s očekávaným chováním (Požadavky).

A jak poznáte, jaké je očekávané chování?

Poznáte to tak, že si pečlivě přečtete nebo poslechnete požadavky a zcela jim porozumíte. Pamatujte, že úplné pochopení požadavků je velmi velmi důležité.

Představte si sami sebe jako koncového uživatele toho, co budete testovat. Poté již nejste vázáni, na dokument s požadavky na software nebo slova v něm. Pak můžete pochopit jádro požadavku a kontrolovat chování systému nejen podle toho, co je napsáno nebo řečeno, ale také podle vlastního chápání a podle věcí, které napsány nebo řečeny nejsou.

Občas může jít o opomenutý požadavek (neúplný požadavek) nebo implicitní požadavek (něco, co není třeba zvlášť uvádět, ale mělo by to být splněno), a i to je třeba otestovat.

Dále, požadavek nemusí být nutně dokumentovaný. Můžete velmi dobře znát funkčnost softwaru nebo ji dokonce odhadnout a pak testovat postupně. Obecně tomu říkáme ad-hoc testování nebo průzkumné testování.

Podívejme se na to do hloubky:

Nejprve si uvědomme skutečnost – ať už srovnáváte testování softwarové aplikace nebo něčeho jiného (řekněme vozidla), koncept zůstává stejný. Přístup, nástroje a priority se mohou lišit, ale základní cíl zůstává STEJNÝ a je PROSTÝ, tj. porovnání skutečného chování s chováním očekávaným.

Za druhé – Testování je jako postoj nebo myšlení, které by mělo vycházet zevnitř. Dovednosti se lze naučit, ale úspěšným testerem se stanete pouze tehdy, když v sobě budete mít několik vlastností standardně. Když říkám, že se lze naučit testovací dovednosti, mám na mysli cílené a formální vzdělávání kolem procesu testování softwaru.

Ale jaké jsou vlastnosti úspěšného testera? Můžete si o nich přečíst na níže uvedeném odkazu:

Přečtěte si jej zde =>Qualities of Highly Effective Testers

Důrazně doporučuji projít si výše uvedený článek, než budete pokračovat v tomto návodu. Pomůže vám porovnat vaše vlastnosti s těmi, které se očekávají v roli testera softwaru.

Pro ty, kteří nemají čas si článek projít, uvádím shrnutí:

„Na vaší zvědavosti, pozornosti, disciplíně, logickém myšlení, vášni pro práci a schopnosti pitvat věci velmi záleží, abyste se stali destruktivním a úspěšným testerem. U mě to fungovalo a pevně věřím, že to bude fungovat i u vás. Pokud tyto vlastnosti již máte, pak to skutečně musí fungovat i pro vás.“

Hovořili jsme o základních předpokladech pro to, abyste se mohli stát testerem softwaru. Nyní pochopíme, proč manuální testování má a vždy bude mít svou samostatnou existenci, ať už s rozvojem automatického testování, nebo bez něj.

Proč je manuální testování nutné?“

Víte, co je nejlepší na tom být testerem, a to i manuálním?

Je to skutečnost, že zde nemůžete spoléhat pouze na dovednosti. Musíte mít/rozvíjet a zdokonalovat svůj myšlenkový proces. To je něco, co si opravdu nemůžete koupit za pár dolarů. Sami na tom musíte pracovat.

Musíte si vypěstovat návyk klást otázky a při testování se na ně budete muset ptát každou minutu. Většinou byste tyto otázky měli klást sami sobě než ostatním.

Doufám, že jste si prošli článek, který jsem vám doporučil v předchozí části (tj. vlastnosti vysoce efektivních testerů). Pokud ano, pak byste věděli, že testování je považováno za myšlenkový proces a to, jak budete jako tester úspěšní, zcela závisí na vlastnostech, které máte jako člověk.

Podívejme se na tento jednoduchý průběh:

• Něco děláte (provádíte činnosti) a zároveň to pozorujete s určitým záměrem (porovnáváte s očekávaným). Nyní zde přichází ke slovu tvé pozorovací schopnosti a disciplína k provádění věcí.
• Voila! Co to bylo? Něčeho sis všiml. Všiml sis toho, protože jsi věnoval dokonalou pozornost detailům před sebou. Nenecháš to být, protože jsi zvědavý. Nebylo to v tvém plánu, že se stane něco nečekaného/zvláštního, všimneš si toho a budeš to dále zkoumat. Ale teď to děláte. Můžete to nechat být. Ale neměl bys to nechat být.“
• Jsi šťastný, že jsi zjistil příčinu, kroky a scénář. Nyní to řádně a konstruktivně sdělíte vývojovému týmu a ostatním zúčastněným stranám ve vašem týmu. Můžete to udělat prostřednictvím nějakého nástroje pro sledování závad nebo ústně, ale musíte se ujistit, že to sdělujete konstruktivně.
• Oops! Co když to udělám tímto způsobem? Co když jako vstup zadám správné celé číslo, ale s úvodními bílými mezerami? Co když… Co když… Co když? Neskončí to snadno, nemělo by to skončit snadno. Představíte si spoustu situací & scénářů a skutečně budete v pokušení je také provést.

Níže uvedené schéma představuje život testera:

Přečtěte si ještě jednou ty čtyři výše uvedené odrážky. Všimli jste si, že jsem je velmi zkrátil, ale přesto jsem zdůraznil nejbohatší část práce manuálního testera? A všimli jste si tučného zvýraznění nad několika slovy? To jsou právě ty nejdůležitější vlastnosti, které manuální tester potřebuje.

No, opravdu si myslíte, že tyto úkony lze zcela nahradit něčím jiným? A horký trend dneška – může je někdy nahradit automatizace?“

V SDLC s jakoukoli metodikou vývoje zůstává vždy jen málo věcí konstantních. Jako tester budete konzumovat požadavky, převádět je na Testovací scénáře/Testovací případy. Tyto testovací případy pak provedete nebo přímo zautomatizujete (vím, že to dělá několik firem).

Při automatizaci je vaše zaměření stabilní, což je automatizace napsaných kroků.

Vraťme se k formální části, tj. k provádění ručně napsaných testovacích případů.

Tady se nesoustředíte pouze na provádění napsaných testovacích případů, ale provádíte při tom také spoustu průzkumných testů. Pamatujete si, že jste zvědaví? A představíte si to. A neodoláte a skutečně uděláte to, co jste si představovali.

Níže uvedený obrázek znázorňuje, jak se zjednodušuje psaní testovacích případů:

Vyplňuji formulář a jsem hotov s vyplněním prvního pole. Jsem líný jít pro myš, abych přesunul fokus na další pole. Stisknu klávesu ‚tabelátor‘. Jsem hotov s vyplňováním dalšího a také posledního pole, nyní musím kliknout na tlačítko Odeslat, fokus je stále na posledním poli.

Oops, omylem jsem stiskl klávesu ‚Enter‘. Podívám se, co se stalo. NEBO je tam tlačítko odeslat, dvakrát na něj kliknu. Nejsem spokojen. Kliknu na něj několikrát, příliš rychle.

Všimli jste si toho? Existuje tolik možných uživatelských akcí, zamýšlených i nezamýšlených.

Nepodaří se vám napsat všechny testovací případy, které stoprocentně pokryjí vaši testovanou aplikaci. To se musí dít průzkumným způsobem.

V průběhu testování aplikace budete pokračovat v přidávání nových testovacích případů. Budou to testovací případy pro chyby, na které jste narazili a pro které dříve nebyl napsán žádný testovací případ. Nebo během testování něco spustilo váš myšlenkový proces a vy jste získali několik dalších testovacích případů, které budete chtít přidat do sady testovacích případů a provést.

Ani po tom všem není zaručeno, že neexistují žádné skryté chyby. Software s nulovým počtem chyb je mýtus. Můžete se pouze zaměřit na to, aby se přiblížil nule, ale to se prostě nemůže stát bez lidské mysli, která se neustále zaměřuje na totéž, podobně, ale ne pouze na proces příkladu, který jsme viděli výše.

Přinejmenším k dnešnímu dni neexistuje software, který by myslel jako lidská mysl, pozoroval jako lidské oko, kladl otázky a odpovídal jako člověk a pak prováděl zamýšlené i nezamýšlené akce. I kdyby něco takového vzniklo, čí mysl, myšlení a oko bude napodobovat? Vaše nebo moje? My, lidé, také nemáme stejné právo. Každý jsme jiný. Tedy?“

Potřeba manuálního testování, když je kolem automatizace:

Automatické testování má v dnešní době svůj díl slávy a v příštích letech jí bude mít ještě více, ale, prostě nemůže nahradit manuální testování QA (čti lidské/explorační testování).

Jistě jste už někdy slyšeli – „Neautomatizujete testování, automatizujete kontrolu“. Tato věta hodně vypovídá o tom, jak si stojí manuální QA testování s automatizačním testováním okolo. Na toto téma psalo a mluvilo mnoho velkých jmen po celém světě, takže to nebudu příliš zdůrazňovat.

Automatizace nemůže nahradit lidské testování, protože:

• Požaduje runtime úsudky o všem, co se děje před vašima očima (při testování) a v několika případech i za scénou.
• Vyžaduje jasné a soustavné pozorování.
• Vyžaduje kladení otázek.
• Vyžaduje zkoumání.
• Vyžaduje uvažování.
• Vyžaduje neplánované akce podle potřeby při testování.

Testování lze nahradit nástrojem/strojem, který bude schopen vstřebat detaily, zpracovat je, nařídit akce a provést je jako lidská mysl a člověk, a to vše za běhu a ve všech možných souvislostech. Tento nástroj opět musí být jako všichni možní lidé.

Takže stručně řečeno, lidské testování nelze nahradit. Možná se tomu za pár let přiblíží nějaký hollywoodský sci-fi film, ale v reálném životě si to nedovedu představit dříve než za několik set let. Nebudu to ale odepisovat navždy, protože věřím v nekonečné možnosti.

Jinak, i kdyby k tomu za pár set let skutečně došlo, obraz, který si dovedu představit, je určitě obrazem děsivého světa. Věk Transformerů 🙂

=>> Doporučená četba – Nejlepší společnosti poskytující služby manuálního testování

Jak automatizace doplňuje manuální testování?“

Již dříve jsem říkal a říkám to znovu, že automatizaci už nelze ignorovat. Ve světě, kde se kontinuální integrace, kontinuální dodávka a kontinuální nasazení stávají povinnými věcmi, nemůže kontinuální testování zahálet. Musíme najít způsoby, jak to udělat.

Většinou nasazování dalších a dalších pracovních sil z dlouhodobého hlediska tomuto úkolu nepomáhá. Proto se musí tester (vedoucí testu/architekt/manažer) obezřetně rozhodnout, co automatizovat a co by se ještě mělo dělat ručně.

Stává se nesmírně důležité mít napsané velmi přesné testy/kontroly, aby je bylo možné automatizovat bez jakýchkoli odchylek od původního očekávání a aby je bylo možné použít při regresi produktu v rámci „průběžného testování“.

Poznámka: Slovo kontinuální z termínu ‚Continuous Testing‘ podléhá podmíněným a logickým voláním podobně jako ostatní termíny, které jsme použili výše se stejnou předponou. Kontinuální v tomto kontextu znamená stále častěji a rychleji než včera. Zatímco ve významu to může velmi dobře znamenat každou sekundu nebo nanosekundu.

Bez dokonalé shody lidských testerů a automatizovaných kontrol (testů s přesně zdokumentovanými kroky, očekávaným výsledkem a výstupními kritérii zmíněného testu) je dosažení kontinuálního testování velmi obtížné a to zase ztíží kontinuální integraci, kontinuální dodávku a kontinuální nasazení.

Záměrně jsem výše použil termín výstupní kritéria testu. Naše automatizační garnitury se již nemohou podobat těm tradičním. Musíme zajistit, aby v případě selhání selhaly rychle. A aby selhaly rychle, měla by být automatizována i výstupní kritéria.

Příklad:

Řekněme, že existuje závada blokování, při které se nemohu přihlásit na Facebook.

Funkce přihlášení pak musí být vaší první automatizovanou kontrolou a vaše automatizační sada by neměla spouštět další kontroly, kde je přihlášení podmínkou, jako je odeslání statusu. Velmi dobře víte, že to určitě selže. Udělejte ji tedy tak, aby selhala rychleji, zveřejněte výsledky rychleji, aby bylo možné závadu rychleji vyřešit.

Další věc je opět něco, co jste už určitě slyšeli – Nemůžete a neměli byste se snažit automatizovat všechno.

Vyberte testovací případy, které, pokud budou automatizovány, budou pro lidské testery značným přínosem a mají dobrou návratnost investic. V této věci platí obecné pravidlo, které říká, že byste se měli snažit automatizovat všechny testovací případy s prioritou 1, a pokud je to možné, pak s prioritou 2.

Automatizace není snadná na implementaci a je časově náročná, proto se doporučuje vyhnout se automatizaci případů s nízkou prioritou alespoň do doby, než budete hotovi s těmi s vysokou. Výběr toho, co automatizovat, a zaměření se na to zlepšuje kvalitu aplikace, pokud se používá a udržuje průběžně.

Závěr

Doufám, že jste již museli pochopit, proč a jak moc je manuální/lidské testování nutné k dodání kvalitních produktů a jak ho doplňuje automatizace.

Přijetí důležitosti manuálního testování QA a vědomí, proč je výjimečné, je úplně prvním krokem k tomu, abyste byli vynikajícím manuálním testerem.

V našich nadcházejících tutoriálech o manuálním testování se budeme zabývat obecným přístupem k provádění manuálního testování, tím, jak bude koexistovat s automatizací, a také mnoha dalšími důležitými aspekty.

Jsem si jistý, že jakmile projdete celý seznam tutoriálů v této sérii, získáte obrovské znalosti o testování softwaru.