Základy testování 2. část

Pokračování článku Základy testování 1. část.

Testování lokalizace

  • Přepínání mezi různými jazyky (km – míle, cz – aj, měny, datum atd.).
  • Formáty data, měn a jednotek (peněžní údaje, špatné znakové sady),[UTF8-nejpoužívanější znaková sada v čechách]. 

Testy použitelnosti

  • GUI – Grafické uživatelské rozhraní – Graphic User Interface 

> Intuitivní

> Konzistentní

> Flexibilní

> Pohodlné = rychlé prostředí

> Správné = gramatika, tlačítka

> Užitečné

  • Použitelnost pro hendikepované
  • Stránka nemá nic říkat, ve videích titulky
  • Čtečky textu pro nevidomé 

Testování webových stránek

  • Texty – vše přečíst.
  • Odkazy – všechny ozkoušet, telefonní čísla
  • Mapa stránek  – celou projít, proklikat, zkontrolovat aktuálnost
  • Gramatika
  • Rychlost – Browser, existují speciální aplikace 
  • Formuláře – vše vyzkoušet 

Testovací případ – Test Case

* Testuje se podle zadaných kroků nadřízeného

* Skládá se z testovacích kroků:

> Obsah:

= Identifikátor

= Testovaná položka – funkce

= Vstupy

= Výstupy

= Požadavky na prostředí

= Zvláštní procedurální požadavky

= Vzájemné závislosti případů

Vlastnosti TC:

  • Jeden možný výsledek
  • Srozumitelnost
  • Jednoznačnost
  • Jedinečnost

! Test Case není co test scénář !

Use case,

 česky případ užití, je termín označující v oborech jako Human–Computer Interaction (interakce člověka s počítačem) či interakční design metodu popisu sekvence kroků, který vykonává uživatel při plnění konkrétního úkolu za použití interagujícího systému (konkrétního softwarového či hardwarového produktu). Takovým úkolem může být například vytvoření určitého typu dokumentu v textovém editoru, nákup v internetovém obchodě, přečtení článku na zpravodajském serveru, ale například i výběr z bankomatu. Ve zvláštních případech může jít o interakci dvou strojů, z nichž jeden plní konkrétní úkol (například synchronizace zařízení).

Use case je složen ze sledu kroků, které uživatel vykonává, aby daný úkol splnil. Pro popis use case bývá užíván specializovaný jazyk Unified Modeling Language (UML)[1], který formou diagramu popisuje jednotlivé akce uživatele a reakce systému, ale celou interakci je možné popsat i jednoduše slovně.

Testovací scénář

  • Skupina logicky souvisejících testovacích případů (např: přihlášení)
  • Plán testů > nejdůležitější dokument > Píše nadřízený
  • Obecný dokument, který popisuje, kdy a jak se bude testovat.
  • Nejsou v něm uvedeny konkrétní hodnoty, ale pouze návrhy testů

Test Report

  • Zpráva o výsledcích testů
  • Pro zákazníka
  • Obsah:

> seznam testů, které byly provedeny

> zhodnocení úspěšnosti testů

> přehled nalezených chyb

> vyvstalé problémy

> návrhy na vylepšení testů

Manuální testovaní

Jedná se o testy prováděné přímo testerem podle testovacích případů (testcase). V dnešní době je již ve spoustě oblastech na ústupu a je nahrazováno automatizovaným testováním. Stále má ale své nenahraditelné místo v některých oblastech (např. exploratory testování).

Automatizované testování

Automatizace je hnacím pohonem pokroku, a tedy i v testování zažívá v posledních letech enormní nárůst. Automatizace je často prováděna pomocí skriptovacích jazyků (např. Python) a jejím cílem je ověřit opakující se scénáře za pomoci krátkých programů. 

  • Kódování > testování > oprava > testování
  • Opakované testování = Regresivní testovaní neboli zpětné
  • Rychlost, efektivita, správnost a přesnost, neúnavnost 
  • Změny musí být aktuální, flexibilní na změny (změna úvodní stránky)
  • Vyplatí se u dlouhodobých projektů

Nástroj selenium:

  • Klikací nástroj na automatizované testování web stránek
  • Plugin
  • Převod do různých programovacích jazyků např: Java

Reportovací systémy

Bugzilla

Atlassian Jira

HP Quality Center

  • Zaznamenávání chyb
  • Záznamenávání úkolů
  • Zaznamenávání test casu
  • Výkazi práce

Pravidla Bug Report

  • Je stručné.
  • Přesné a podrobné.
  • Napsané v neutrálním tónu (bez ironie, ponižování členů týmu).
  • Zaobírá se jedinou chybou.
  • Ale postihuje ji v její nejobecnější podobě – zda má chyba i jiné projevy, zda se vyskytuje jinde (zda je na jednom nebo více formulářích).
  • Popisuje jak je možné chybu chybu reprodukovat – postup krok za krokem k ní.
  • A na koho bude mít chyba dopad.
  • Poskytuje co nejvíce informací pro hledání problému při ladění.
  • Předkládat důkazy o chybě.

Jak ne: nejde se přihlásit, nejde to, …..

Závažnost vs priorita – Severity vs Priority

Závažnost

  1. Nejvyšší závažnost – nejde používat
  2. Provozní chyba – ztráta funkčnosti (e-shop nejde objednávka)
  3. Chyba v textu
  4. Připomínka

Priorita

  1. Rychle opravit, výrazně viditelná chyba
  2. Opravit než půjde do produkce
  3. Měla by se opravit
  4. Může zůstat – okrajová chyba 

Příklady:

1/3 ztrácíme data / jeden z tisíce uživatelů

3/2 chyba v manuálu / opravit před vydáním (release)

1/1 (áčkové chyby) havárie app / nejdou objednávky

O chybách se poradit z nadřízeným

Metodiky vývoje software

Souhrn postupů, pravidel a nástrojů, používaných pro návrh plánování a řízení vývoje softwaru a zároveň obor, který se zabývá vytvářením, porovnáváním a ovlivňováním jednotlivých metodik vývoje softwaru.

  • Vodopád:

> definice požadavků

> návrhy systému

> implantace 

> ověřování

> údržba

  • Spirálový model

  • Agilní metodiky 

> rychlý vývoj

> reakce na změnu požadavků

> prototypování

  • Scrum

Validace vs Verifikace

  • Validace – zda jsou splněny požadavky zákazníka (to co očekává)
  • Verifikace – Zda je splněna specifikace / návrh

UML – Unified Modeling Language

  • Use case = případ užití
  • Diagram aktivit

UML  je v softwarovém inženýrství grafický jazyk pro vizualizacispecifikaci, navrhování a dokumentaci programových systémů. UML nabízí standardní způsob zápisu jak návrhů systému včetně konceptuálních prvků jako jsou business procesy a systémové funkce, tak konkrétních prvků jako jsou příkazy programovacího jazykadatabázová schémata a znovupoužitelné programové komponenty.

UML podporuje objektově orientovaný přístup k analýze, návrhu a popisu programových systémů. UML neobsahuje způsob, jak se má používat, ani neobsahuje metodiku(y), jak analyzovat, specifikovat či navrhovat programové systémy.

Tipy a triky

  • Hledat chyby tam kde byly
  • Různá zařízení, různé prohlížeče
  • Změnit velikost okna
  • Testovat chybové hlášky – musí být srozumitelné
  • Zkušenosti, intuice, předtucha

Istqb

Certifikace testera, základní stupeň CTFL

Časté pohovorové otázky

  • Co je test case
  • Co je use case
  • Co je test plán
  • Výhody a nevýhody automatizovaného testování, kdy je vhodné použít
  • Jaké znáte deportovací systémy
  • Co obsahuje bug report
  • Rozdíl závažnost a priorita
  • Rozdíl validace a certifikace

„Zkušenost je název, který dáváme svým chybám a omylům.“ —  Oscar Wilde

1 komentář u „Základy testování 2. část“

Napsat komentář