Jste začínající tester nebo plánujete se jím stát a nevíte jak testovat? Narážíte při testování na problémy, s nimiž si nevíte rady? Pak se vám může hodit tento článek, kde si povíme jak software testovat. Jedná se o naprosté základy, nepůjdeme do velkých podrobností. Celý článek je především pro testery, tj. neřeší se zde jak testovat software z pohledu vývojáře nebo zajistit kvalitu z pohledu manažera.
Dnešní software je plný chyb a často jsou na vině vývojové týmy, které nevědí jak testovat a jak chyby odhalit. Jen za poslední týden jsem narazil během používání běžných aplikací na 5 chyb, které mi pořádně znepříjemnily život: v bankovnictví, operačním systému, mobilní aplikaci atd. Pojďme se proto podívat jak na to.
Jak začít?
Důležité je nejdřív pochopit, co to testování softwaru je (viz článek: Co je testování softwaru). Poté si položte otázku, proč chcete testovat SW? Proč chcete hledat chyby? Co je tedy cílem vaší práce? Ano, testování se dělá, protože chceme zajisti kvalitu. Tedy ověřit, že jsou uspokojeny jak explicitní požadavky, tak implicitní požadavky. A to je také hlavní záležitost, která určuje, jak testovat software. Potřebujete znát, jaké jsou požadavky na testovaný SW, abyste věděli co ověřit a vyzkoušet. To se běžně dozvíte během plánování od vedoucího vývoje/týmu nebo v agilním vývoji od Product Ownera. Když máte požadavky, je tedy jasné, k čemu má software sloužit a co má dělat. Můžete začít s testováním, zda software tyto požadavky splňuje. Tedy pokud je již software nakódován programátory. 🙂
Příklad testování ze života
Řekněme, že mám v požadavku, že bankovní aplikace umožňuje odeslat peníze na cizí účet (tj. příkaz k úhradě). Potřebuji to otestovat. Jak budu přesně postupovat?
-
Nejprve ověřím základní funkcionalitu – pozitivní případ – což udělám těmito testy:
-
TEST: odeslat peníze na cizí účet
-
zkusím vytvořit jednorázový příkaz k úhradě
-
ověřím, že vše se dá zadat snadno a intuitivně (pokud je to cílem produktu)
-
ověřím výstup, tedy že se peníze odeslaly (probíhá na testovacím prostředí)
-
-
TEST: ověřit možnost editovat pole po zadání hodnoty
-
-
Ověřím základní funkcionalitu – negativní případ – což udělám těmito testy:
-
TEST: na účtu není dostatek peněz
-
vyberu/přirpravím účet se zůstatkem 1.000,- Kč
-
vyplním formulář s částkou 1.001,- Kč
-
odešlu formulář
-
očekávané chování: Aplikace zahlásí chybu: „Nedostatek finančních prostředků“
-
-
TEST: nejsou vyplněna povinná pole
-
-
Prověřím vstupy (vstupní pole), a to prostřednictvím negativních testů:
-
my si to ukážeme např. na vstupním poli Částka (viz obrázek)
-
cílem je, že se software musí chovat korektně i při neplatných hodnotách zadaných do pole částka, jako:
-
„-1“
-
„asdasdasd“
-
dlouhý řetězec
-
velmi vysoké číslo
-
nezadáte nic
-
-
Můžete také pomoci vývojářům a poradit jim, že ideální bude, pokud tam nepůjde zadat ani písmeno nebo mínus.
-
Toto musím provést s každým vstupním polem – každé vstupní pole je ale něčím specifické, a proto i jeho otestování (tj. zda se chová, jak má) bude různé. Podstatné je ověřit, zda vstupům odpovídají správné výstupy, tj. chybové hlášky. Platební příkaz je odeslán, pokud je částka i formulář korektní. A je zahlášena chyba, pokud je částka neplatná nebo jsou ve formuláři chyby.
-
Technik jak testovat je spoustu. O těch nejčastějších píšu ve článku Techniky testování a řeším je také na kurzu. Důležité je stanovit si, kolik času na testování máte. A poté naplánovat vhodný počet testů. Vyčerpávající testování totiž není možné. Proto je důležité si stanovit hranice. S tím nám také může pomoci, když si testy budeme zaznamenávat.
Záznam testů
Vymyslet jak příslušnou funkcionalitu otestovat (jak jsme si ukázali v předchozím odstavci), je často časově náročné. Proto nechceme, abychom pokaždé museli vzpomínat, jaké testy jsme to vlastně na minulé verzi dělali. Z tohoto důvodu je velmi vhodné si testy zapisovat. Nejlepším způsobem záznamu testů je test management tool. Což je nástroj přímo určený pro správu testů. Další výhodou při zaznamenávání testů je pak snadné reportování výsledků, co vše bylo otestováno na konkrétní verzi. Pokud ale pracujete v „ortodoxních“ agilních týmech a reportování je pro vás sprosté slovo související s pokusem managementu kecat vám do práce… 🙂 pak vám bude stačit nějaký checklist nebo TestPad. Pokud si testy evidujete, je snadné i plánování, co se bude testovat na konkrétní verzi (releasu). Těmto seznamům se říká test plány. Stačí do nich přidat všechny testy, které plánujete na konkrétní verzi vykonat. Test management tooly umožňují jednoduchou správu těchto test plánů. Naprosto zásadním testplánem je regresní sada sloužící k regresnímu testování (více v článku Regresní testování). Nebo smoke sada, která nám určuje, zda produkt vůbec funguje a má smysl začít jej testovat. Dobré je si také uvědomit, kde chyby vznikají.
Kde chyby vznikají?
Spousta nováčků si mylně myslí, že chyby vznikají jen ve fázi implementace, tedy programování. Ve skutečnosti chyby vznikají ve všech fázích vývoje SW při:
-
analýze požadavků,
-
designu systému,
-
implementaci,
-
testování,
-
i releasu.
Je tedy nutné testovat (nebo také dávat zpětnou vazbu) ve všech fázích vývoje. Důležité je, aby vám s testováním pomohli i ostatní členové týmu. Vše není jen na testerech! Při představení požadavků můžete rovnou komentovat svou představu, jak to bude uživateli vyhovovat nebo nebude. A tedy předejít chybným zadáním. Stejně tak při návrhu systému, který bude mít jasný dopad na funkci a využívání softwaru, je vhodné pokládat dotazy. Ty rozkryjí, co to bude znamenat pro uživatele. Testování ve fází implementace je již na vývojářích, kteří si pomocí Unit testů musí ověřit funkčnost nového kódu.
Tester pak přichází na řadu, aby ověřil, že nová funkcionalita splňuje požadavky a „nerozbila“ již fungující části.
Závěr
Nezapomínejte také na to, že testovaní není jen ověření funkcionality, ale také dalších parametrů kvality: výkonnost, bezpečnost, použitelnost, kompatibilita, portabilita, spolehlivost a udržitelnost. Téma je velmi obsáhlé a není možné jej obsáhnout v jednom článku. A je běžné, že se narazí na problémy, jak mám stihnout vše otestovat. Vždyť těch možností jsou tisíce?! Jak si připravit testovací scénáře, abych pár kroky ověřil vše podstatné? Proto jsem připravil celodenní kurz Základy testování softwaru, kde se problematice věnuji podrobněji. Zařadil jsem i praktická cvičení pro osvojení probírané problematiky. Příště si povíme více o testovacích technikách.
