Jak na výběr testů pro frontend?

CO JE to TEST ANALÝZA?

Než se pustíme do vybírání testů, podíváme se nejdříve na to co je to test analýza, v rámci které testy vytváříme.

Test analýza je proces, ve kterém analyzujeme specifikace softwarového produktu s cílem identifikovat, co by mělo být testováno.

To zahrnuje pochopení požadavků na software, identifikaci rizikových oblastí, a vytvoření struktury pro další fáze testování.

Výsledkem testovací analýzy jsou testovací podmínky, které slouží jako základ pro vytvoření testovacích případů.

Co je to testovací podmínka?

Testovací podmínka je formálně specifikovaný požadavek, který musí být ověřen při testování. Testovací podmínky jsou vytvořeny během fáze testovací analýzy a slouží jako základ pro vytváření konkrétních testů.

Příklady Testovacích Podmínek:

• Ověření, že uživatelské jméno musí obsahovat minimálně 6 znaků.
• Ověření, že databázový dotaz vrací správné výsledky.
• Ověření, že webová stránka se načte do 3 sekund.
• Ověření, že aplikace nepovolí neautorizovaný přístup k citlivým datům.

Funkcionální testování

V dnešním článku se zaměříme na vybírání funkcionálních testů v rámci testování frontendu aplikací.

Co je to Frontend testování?

Frontend testování přistupuje k aplikaci skrz její grafické rozhraní (GUI) a interaguje přímo s jejími prvky. Tento přístup je nebližší tomu, co provádí běžný uživatel aplikace.

Co to vlastně znamená?

Funkcionální testování se soustředí na ověření funkcí aplikace, aby se zajistilo, že vše pracuje, jak má.

Vycházíme většinou ze zadávací dokumentace, kde jsou jednotlivé požadavky na software popsány

Opakem funkcionálního testování je nefunkcionální testování. To se zaměřuje na vlastnosti systémy jako jsou například:

• Rychlost a výkon,
• Použitelnost,
• Bezpečnost,
• Spolehlivost,
• Kompatibilita.

Běžné techniky pro výběr testů

My se nyní ale už přesuneme k výběru jednotlivých testů. Testování můžeme rozdělit na různé části, jako je například: black-box, white-box, exploratory.

Jaké ale máme obecná pravidla pro výběr testů? Myslete vždy na tyto scénáře:

• Pozitivní testy – testy, které mají za cíl projít úspěšně procesem (například registrace uživatele na e-shopu).
• Negativní testy – testy, které ověřují neplatné vstupy nebo neočekávané uživatelské chování (například zadání nevalidního e-mailu do formuláře).
• Edge case (hraniční případy) – testy, které ověřují nepravděpodobné extrémní případy (například zadání 1 milionu znaků do kontaktní zprávy).

Z mých zkušeností je ze strany uživatelů objeveno nejvíce kritických chyb, pokud dělají něco, co vývojový tým nepředpokládal.

Negativní testy a edge casy proto často objevují právě chyby typu pády aplikace či jiné závažné chyby.

Nyní se ale podíváme na to, jaké konkrétní techniky můžeme použít pro testování aplikace.

Formulářové testy

Často testujeme formuláře, které jsou také častým zdrojem chyb.

V této kapitole se podíváme na to, jaké testy zvolit pro jejich testování.

Pokud testujete formuláře a jejich pole, doporučím testovat pomocí hodnot níže:

• Správné hodnoty: minimum, maximum znaků, diakritika,
• Nesprávné hodnoty: text do čísla, více/méně znaků, než je limit,
• Speciální znaky (například čínština, vykřičník, zavináč atd.),
• Vyplnění/nevyplnění nepovinného pole,
• Emoji,
• Datové pole: datum v minulosti, v budoucnosti, rok 3000, 30. únor, 13. měsíc,
• Extrémní hodnoty,

Možná vás napadne, že je to spousta testů na každé pole ve formuláři. Ze své zkušenosti ale můžu uvést příklady, kdy se mi je oplatilo udělat:

• Použití emoji v interním incident report nástroji způsobilo pád databáze.
• Běžně se setkávám s tím, že pole nejsou limitovaná na maximální či minimální počet znaků.
• Na jednom projektu se mi povedlo rozbít databázi a tím celou aplikaci tím, že jsem do pole pro dlouhou zprávu zadal text, který měl 100.000 znaků.
• Jednou se mi dokonce stalo, že pole e-mail nebylo povinné, i když mělo být. Bohužel jsem to v testech neodhalil a způsobilo to velké problémy na produkci.

Pokud testujete funkcionality, které mají definovaný rozsah (například věk), pak můžete použít třídy ekvivalence s analýzou hranic.

Co to je?

Třída ekvivalence

Třída ekvivalence (Equivalence Partitioning – EP) je množina vstupních hodnot, které by měly systém prověřit stejným způsobem a které by měly produkovat stejný výstup.

Proč je dobré testy psát pro třídy ekvivalence a následně také pro hraniční hodnoty?

Tato pole jsou naprogramována v programu pomocí podmínek.

Vývojář v těchto podmínkách může udělat chybu.

Třída ekvivalence ověřuje, zda-li jsou všechny požadované části pole naprogramovány.

Představme si, že máme pole na webové stránce, které akceptuje čísla od 1 do 100. Můžeme definovat tři třídy ekvivalence:

1. Neplatné čísla menší než 1
2. Platné čísla od 1 do 100
3. Neplatné čísla větší než 100

Testování jedné hodnoty z každé třídy ekvivalence by mělo být dostatečné k ověření, že pole správně zpracovává všechny hodnoty.

analýza hraničních hodnot

Analýza hraničních hodnot (Boundary Value Analysis – BVA) se zaměřuje na testování hodnot na okrajích jednotlivých tříd ekvivalence.

Testy vyplývající z analýzy hraničních hodnot ověřují, jestli jsou hodnoty v podmínkách, které určují chování pole naprogramovány správně.

Existují různé typy BVA:

• BVA-2 – pro testování se používají hraniční hodnoty na krajích jednotlivých tříd ekvivalence.
• BVA-3 – rozšiřuje BVA-2 tak, že se testuje: hraniční hodnota, hraniční hodnota -1, hraniční hodnota +1

My se dnes zaměříme na BVA-2, která je pro většinu testování dostatečná.

Použijeme stejný příklad s polem, které akceptuje čísla od 1 do 100.

Přepoužijeme třídy ekvivalence, které jsem definovali v předchozím příkladu.

V BVA-2 použijeme hraniční hodnot obou stran tříd ekvivalence.

Hraniční hodnoty zde budou:

• Neplatná hodnota 0 (dolní limit minus 1)
• Platná hodnota 1 (dolní limit)
• Platná hodnota 100 (horní limit)
• Neplatná hodnota 101 (horní limit plus 1)

Těchto několik testů na hraničních hodnotách nám pomůže zjistit, zda pole správně omezuje vstup.

Největší efektivity dosáhnete, pokud zkombinujete testování dle tříd ekvivalence spolu s testováním hranic.

Příklady využití EP + BVA:

• Vypočítávání úrokové sazby dle zůstatku na účtu.
• Použití slevy závislé na věku.
• Textová pole s minimálním a maximálním počtem znaků.
• Maximální velikost souboru při uploadu.

Rozhodovací tabulka

Pokud máme testovat část aplikace, která se chová různě dle uživatelských vstupů je dobré pro tyto vstupy použít rozhodovací tabulku.

Rozhodovací tabulka je tabulková struktura, která mapuje různé vstupní podmínky na předpokládané výsledky (výstupy). Každý sloupec v tabulce představuje jednotlivý test a každý řádek odpovídá určitému vstupu nebo výstupu.

Příklad rozhodovací tabulky:

Představme si jednoduchý příklad e-shopu, který nabízí slevy zákazníkům na základě věku a členství v bonusovém programu:

Podmínky/test ID	TC1	TC2	TC3	TC4
Věk > 60 let	Ano	Ano	Ne	Ne
Členství v bonusovém programu	Ano	Ne	Ano	Ne
Sleva:	20 %	10 %	10 %	0 %

Výhody použití rozhodovacích tabulky:

• Jednoduchá vizualizace komplexních podmínek.
• Možnost rychlého identifikování chyb.
• Redukuje riziko zapomenutí na určitou kombinaci vstupů.

Nevýhody:

• Pro velmi komplexní systémy může být tabulka příliš rozsáhlá.
• Není vhodná pro dynamické systémy, kde se pravidla často mění.

Jakou techniku použít, pokud máte komplexnější aplikaci s mnoha vstupy? Pomoc s výběrem testů vám může pomoci pairwise technika, která za pomoci kombinatoriky vybírá vhodné testy pro otestování.

My se pairwise technikou budeme zabývat někdy v budoucnu. Do té doby se ale můžete podívat na tento článek webu swtestovani, který problematiku osvětluje.

Závěr

Správný výběr testů je klíčový pro efektivní manuální testování. Výběrem vhodných testovacích případů nejenže zajistíte, že váš software je robustní a bez chyb, ale také optimalizujete své náklady a čas. Děkujeme za přečtení a přejeme hodně úspěchů ve vaší kariéře v testování!

Zajímá vás testování a chcete nastartovat novou kariéru? Připravíme vás na roli testera v naší Testovací Akademii.

---