Logo Light
Published on

Testování ukázkové API aplikace (2. díl) - Testovací plán - UI

Úvod

Tento článek obsahuje testovací plán uživatelského rozhraní aplikace pro správu uživatelů. Navazuje na první díl, který popisoval testovací plán backenové části aplikace.

1. Cíl testování

Ověření funkčnosti aplikace z pohledu uživatele - zajistit, že hlavní funkce jako registrace, přihlášení, správa uživatelů a odhlášení fungují správně v běžných i hraničních případech.

2. Rozsah testování

Do rozsahu testování spadá:

  • Přihlášení a odhlášení uživatele, přístup k chráněným částem aplikace
  • Zobrazení seznamu uživatelů
  • Vytvoření nového uživatele
  • Úprava existujícího uživatele
  • Mazání uživatele

Mimo rozsah testování je:

  • Testování API
  • Testování responzivního designu nebo kompatibility mezi prohlížeči
  • Nefunkční testy (výkon, škálování, ...)

Úrovně testů

  1. Systémově - Integrační testy
  2. End-to-End (E2E)

3. Zdroje

Členové týmu

V rámci tohoto článku nebudu řešit konkrétní rozdělení rolí (QA, vývojář, DevOps). Předpokládáme, že testování provádí jeden tester.

V reálném projektu by zde byly uvedeny role (QA, vývojář, produktový manažer) a odpovědnosti.

Testovací nástroje

  • Playwright

Testovací prostředí

  • Testovací prostředí oddělené od produkce
  • CI/CD pipeline (GitHub Actions)

Testovací data

  • tstovací data budou generována v rámci jednotlivých scénářů

4. Rizika

  • Chybějící rollback testovacích dat (Pokud testy zanechávají data ve vývojovém prostředí, mohou ovlivnit výsledky dalších testů)
  • Závislost na dostupnosti backendového API (pokud je API nedostupné nebo nestabilní, nemohou být některé UI testy provedeny)

5. Časová osa

Odhad pracnosti pro základní testy:

  • 4h: seznámení s aplikací, technologií a testovacím plánem
  • 4h: vytvoření základní struktury testů v Playwrightu
  • 4h: implementace testů pro přihlášení/odhlášení
  • 8h: testy pro zobrazení, přidávání, úpravu a mazání uživatelů
  • 4h: ošetření hraničních hodnot (prázdná pole, špatné údaje, ...)
  • 4h: testy autorizace – přístup bez JWT tokenu, redirecty
  • 4h: spouštění a ladění testů
  • 4h: integrace do CI/CD pipeline
  • 4h: vyhodnocení a reporting

Celkem přibližně 5 dní práce pro jednoho QA/testera.

6. Výstupy

  • Testovací plán (tento dokument)
  • Sada automatizovaných testů (Playwright)
  • Test report (výsledky úspěšných a neúspěšných testů)
  • CI/CD integrace testů

7. Akceptační kritéria

  • všechny CRUD operace musí být PASSED
  • autentizace a autorizace fungují
  • chyby a výjimky jsou vhodně ošetřeny a vrací smysluplné odpovědi
  • nesmí být evidována žádná chyba se závažností CRITICAL

8. Použitá dokumentace

Testovací scénáře

Použité zkratky: POS - positivní scénář (správný průběh) NEG - negativní scénář (chybné nebo neautorizované požadavky)

1. Autentizace

1. Registrace

  1. Úspěšná registrace (POS)
  2. Neplatný email spustí HTML validaci (NEG)
  3. Duplicitní email (NEG)

2. Login

  1. Správné údaje (POS)
  2. Špatné údaje - chybný e-mail (NEG)
  3. Špatné údaje - chybné heslo (NEG)

3. Logout

  1. Odhlášení odstraní token, vyčistí seznam a změní stav UI (POS)

2. CRUD operace s uživateli

1. Seznam uživatelů

  1. Seznam obsahuje id, name, email, age, role (POS)
  2. Prázdný seznam se korektně zobrazí (POS)

2. Přidání uživatele

  1. Vyplnění a potvrzení formuláře přidá uživatele (POS)
  2. Chybějící povinné údaje (NEG)

3. Editace

  1. Kliknutí na "Edit" vyplní formulář hodnotami (POS)
  2. Změna a potvrzení aktualizuje uživatele (POS)
  3. Zrušení editačního módu navrátí původní formulář (POS)

4. Mazání

  1. Mazání jednoho uživatele funguje korektně (POS)
  2. Delete All Users" odstraní všechny (POS)

3. Validace a chybové stavy

  1. Po odhlášení nejsou dostupné chráněné funkce (POS)

4. Navigace

  1. Odkaz na /swagger funguje (POS)

5. Rozšířené testy

  1. Expirace tokenu (NEG)
  2. Paralelní úpravy uživatelů bez kolizí v UI (POS)