5 důležitých diagramů, které se testeři musí naučit používat

5 important diagrams that testers need learn how use

Pokud ne pro obrázky, neexistovaly by žádné záznamy z rané historie, ucházející znalosti a vývoj jazyka.

Není to příliš dramatizující, ale diagramy mají své vlastní zvláštní místo i ve světě s vysoce vyvinutými a sofistikovanými formami psaní a vyjadřování.

V technologickém průmyslu jsou nám naše diagramy drahé.

Zde jsou některé z prominentních, s nimiž jsme my testeři často v úzkém kontaktu a jak je používáme.

Co se naučíte:

• 5 diagramů, které se testeři musí naučit používat
• # 1) Vývojové diagramy:
• # 2) Schémata přechodu stavu:
• # 3) Kontextové diagramy:
• # 4) Mindmaps:
• # 5) Grafy ER:
• # 6) Bonus: Vysmívat se obrazovky / drátové modely:
• Shrnutí - Jak můžete vytvořit tyto diagramy, pokud potřebujete?
• Doporučené čtení

5 diagramů, které se testeři musí naučit používat

Tady jsme.

# 1) Vývojové diagramy:

Vývojové diagramy jsou nejlepší pro ilustraci procesu. Používají specifické symboly pro každý úkol / typ akce, která se v rámci procesu provádí. Umožňuje rozhodování, větve, smyčky atd., Takže je dokonalým nástrojem pro dokumentaci a porozumění.

Testeri obvykle najdou vývojové diagramy v plánu zkoušek, strategii zkoušek, artefaktech požadavků (BRD, FRD atd.) Nebo v dalších procesních dokumentech.

Nejčastěji používané symboly a jejich význam ve vývojovém diagramu jsou:

• Ovály- Pro spuštění a zastavení
• Obdélníky Pro zpracování / nebo úkol
• Diamant- Pro rozhodnutí

Úplné informace o tvarech vývojového diagramu najdete zde Symboly vývojového diagramu .

Porozumět procesu nebo toku řízení prostřednictvím vývojového diagramu je super jednoduché. Pomáhá při zapamatování, porozumění a slouží jako rychlá reference.

Přečtěte si také => Jak psát složité testovací scénáře obchodní logiky pomocí techniky rozhodovací tabulky

Tady jsou dva způsoby, jak testeři používají vývojové diagramy:

a) Vývojové diagramy pro kontrolní tok a statistickou analýzu:

Cyklomatická složitost je metrika, která nám pomáhá měřit, jak složitý je konkrétní softwarový program. Jednou z možností znalosti Cyclomatic Complexity je, že nám pomáhá pochopit rozsah testování jednotek, které je třeba provést, abychom dosáhli úplného pokrytí (další informace a odkazy níže).

Vývojový diagram je metodou, která k tomuto opatření dospěje.

Naučme se, jak ji vypočítat cyklomatickou složitost pro následující program prostřednictvím řídicího vývojového diagramu.

Jednoduše vytvořte vývojový diagram ovládání, jak je znázorněno níže, a použijte tento vzorec:

Cyklomatická složitost: = Počet připojení nebo řádků - Počet uzlů + 2

Z diagramu je počet uzlů 7 a připojení 7.

Proto je cyklomatická složitost této části kódu 7-7 + 2 = 2.

Potřebujete více informací o tom, jak používat vývojový diagram řízení a cyklomatickou složitost?

Koukni na tohle:

• Korelace mezi cyklometrickou složitostí a pokrytím kódu při testování v bílé krabici
• McCabeova cyklomatická složitost a proč ji nepoužíváme

b) Vývojové diagramy pro ilustraci procesu:

Následuje proces sledování defektů ve formátu vývojového diagramu. Jak vidíte, je velmi snadné vstřebat a implementovat:

(Poznámka:Klikněte na obrázek pro zvětšené zobrazení)

# 2) Schémata přechodu stavu:

Tabulky nebo diagramy přechodu stavu jsou skvělými analytickými nástroji, když se díváte na složité systémy, které procházejí mnoha změnami z jednoho stavu do druhého.

Pro začátečníky, kteří přemýšlejí: „Co je to přechod státu?“ - Představte si žárovku ovládanou přepínačem. Přepínač lze otočit ZAPNUTO / VYPNUTO. Stav, kdy žárovka může být v daném okamžiku, je tedy ZAPNUTÝ nebo VYPNUTÝ a událost / akce způsobující přechod z jednoho stavu do druhého je překlopení spínače.

To lze ukázat ve formě diagramu nebo tabulky. Jako níže:

Jednoduché, že? Pojďme na něco trochu složitějšího. Podívejte se na diagram přechodu stavu pro systém jízdenek. Je to docela přímočaré a snadno pochopitelné.

Vezměte prosím na vědomí, že diagramy přechodu stavu jsou obvykle zaměřeny na obchodní entity a nikoli na vizuální navigaci po stránkách.

Například: Stěžejní obchodní entitou je v našem případě samotný lístek, který je vytvořen prostřednictvím aplikace. První část, výroba lístku, může zahrnovat procházení systému několika stránkami:

• Stránka 1-> Vyberte č. cestujících - dospělých, dětí a seniorů.
• Strana 2-> Vyberte si typ lístku - denní, týdenní, měsíční atd.
• Strana 3-> Zkontrolujte podrobnosti a dokončete.
• Stránka4-> Provést platbu atd.

Může tedy existovat mnoho různých přechodů mezi stránkami, ale samotný lístek je ve stavu, ve kterém je vytvořen. Normálně tedy nevytváříme diagram ST pro vizuální přechody (můžete, pokud chcete, ale není to tak často používáno), děláme to pro přechody stavu základní obchodní entity.

Jakmile je vytvořen diagram ST, můžete jej použít ke snadné identifikaci testovacích scénářů typu end-to-end a transakcí koncových uživatelů, a to následovně:

Tři žluté čáry jsou 3 případy typu end-to-end, které při testování pokryjí nejkritičtější a nejpoužívanější oblasti aplikace. Jedná se o tak užitečný nástroj k vytváření smysluplných testovacích případů a koncových akceptačních testů.

Pro mnohem komplexnější vysvětlení a využití v reálném světě vyzkoušejte => Technika testování přechodového stavu pro testování složitých aplikací

# 3) Kontextové diagramy:

Softwarové systémy zřídka fungují jako nezávislé jednotky. Jednoduché aplikace, jako je kalkulačka, poznámkový blok atd., Mohou fungovat samy, ale podniková aplikace často komunikuje s mnoha dalšími aplikacemi.

Například: Mzdový systém může interagovat s účetní aplikací, systémem pracovních výkazů pro pracovní hodiny a HR portálem pro podrobnosti zaměstnanců. Kontextové diagramy jsou vynikající diagramy, které všechny tyto vztahy představují snadno pochopitelným způsobem.

Následuje kontextový diagram právě popsaného mzdového systému:

Kontextový diagram velmi jasně ukazuje kontext určitého systému se všemi ostatními entitami, které se k němu vztahují. Jednoduché vysvětlení najdete zde =>

Jednoduché vysvětlení najdete zde => Kontextový diagram systému

Kontextové diagramy pomáhají testerům porozumět systému v širším smyslu a pomáhají při vytváření testovacích strategií, které zahrnují tyto příchozí a odchozí vztahy, které má systém s ostatními entitami. Možná nevytváříme kontextový diagram jako součást našeho testovacího procesu, ale pokud je k dispozici, pomáhá skvělému porozumění.

# 4) Mindmaps:

Myšlenková mapa sleduje zaneprázdněnou mysl, která přeskakuje od tématu k tématu; každá myšlenka se s každým nápadem prohlubovala a rozšiřovala. Je to forma diagramu, kdy začínáte svou hlavní myšlenkou a dokumentujete všechny jednotlivé pod-myšlenky, které z ní vycházejí.

nejlepší bezplatný blokování automaticky otevíraných oken pro chrom

Myšlenkové mapy lze použít na cokoli a všechno. Přestože se ještě neobjeví v IEEE, CMMI nebo jiných standardních šablonách nebo procesních dokumentech, jsou stále velmi populární součástí kultury softwarového průmyslu.

Jedním z velmi populárních použití myšlenkových map je sledování průzkumného testování. (Vím, já vím, přemýšlíte, proč je vůbec nutné sledovat průzkumné testování? Je to proto, že s rychlými vývojovými cykly, agilními a jinými rychlejšími metodami vývoje softwaru je pro testery méně pravděpodobné, že najdou čas a prostor pro úplnou dokumentaci. To znamená, že rozsah průzkumu roste a je třeba ho posílit. To mohou za vás udělat myšlenkové mapy.)

Například: Následuje diagram pro aplikaci elektronického obchodování, kde jednoduše sledujete své testování pomocí myšlenkové mapy následovně:

Testeři možná nedostanou myšlenkové mapy jako vstupy. Ale mohli bychom vidět situace, kdy je musíme vytvořit. Je to velmi snadné. Začněte s vaší centrální myšlenkou nebo výchozím bodem a sledujte, kam vás vaše myšlenky zavedou. Existuje mnoho jednoduchých a snadných bezplatných online nástrojů, které můžete použít pro mapování mysli. Toto jsem použil k nakreslení výše uvedeného mapa zde.

Další informace a nástroje najdete na stránce => Mapování mysli při testování softwaru - způsoby, jak zpříjemnit testování!

# 5) Grafy ER:

Pro modelování databáze se používají diagramy vztahů mezi entitami (ER). Pomáhají nám pochopit tabulky, jejich pole a to, jak pole v jedné tabulce souvisí s poli v jiných tabulkách v systému DB. Ukazuje vizuálně komponenty vašeho systému DB a vztahy mezi nimi.

Schémata ER také fungují jako počáteční zkušební provoz modelu DB a vizualizace před navržením a vytvořením systémů DB.

Schémata ER mají entity (instance tabulek DB) a jejich vztahy (jedna ku jedné, jedna k mnoha, jedna k povinným atd.) Reprezentované pomocí krabic a konektorů vrána. )

Schémata ER mají mnoho variací, ale nejjednodušší verze může vypadat níže:

obraz Zdroj

Pro rychlý úvod a vysvětlení zkontrolujte:

• Výukové video s diagramem vztahu mezi entitami (ERD)
• Výukový program diagramu vztahů s entitami (ERD)

# 6) Bonus: Vysmívat se obrazovky / drátové modely:

Drátové rámy jsou buď HTML, nebo jednoduché obrázky (snímky obrazovky), které nám schematicky ukazují budoucí stránku / komponentu uživatelského rozhraní.

Drátové modely jsou pro testery požehnáním, protože nám velmi usnadňují vizualizaci finálního produktu a zlepšování procesu analýzy návrhu testů. To znamená lepší testovací scénáře, lepší testovací případy a zase vyšší účinnost testu.

Drátovými modely mohou být jednoduché ručně kreslené obrázky nebo interaktivně vytvořené struktury webových stránek nebo jakékoli jiné diagramy, které jsou reprezentativní pro finální systém.

Jednoduchý drátový model pro přihlašovací obrazovku může vypadat níže:

Zde je rychlý odkaz k pochopení způsobu, jakým týmy QA používají drátové rámce pro včasné testování a některé nástroje k jejich vytvoření => Drátové modely - měly by být skutečně testovány? A pokud ano, jak?

Shrnutí - Jak můžete vytvořit tyto diagramy, pokud potřebujete?

Testeři většinou interpretují většinu výše uvedených diagramů. Ale zřídka je možná budeme muset vytvořit. MS Visio a SmartDraw jsou skvělé nástroje k použití. Pokud však hledáte něco volného a lehkého (žádná instalace a nastavení), podívejte se zde.

Pokud nemáte přístup k internetu a máte jen své slovo nebo barvu, můžete k vytvoření těchto diagramů použít dostupné tvary (tedy alespoň většina z nich). Toto je moje nejméně oblíbená metoda, protože je časově náročná a není tak uživatelsky přívětivá, ale bude to stačit.

O autorovi: Tento článek je napsán členem našeho týmu Swati.

Jaké diagramy tedy používáte a které jsou vaše oblíbené?

Doporučené čtení

• Poradenství při testování softwaru pro začínající testery
• Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
• Co je Testování komponent nebo Testování modulů (Naučte se s příklady)
• Co je srovnávací testování (naučit se s příklady)
• Ztrácejí testeři kvůli automatizaci přilnavost?
• Globální podnikání v oblasti testování softwaru brzy dosáhne 28,8 miliard dolarů
• Jak udržet živou motivaci v testerech softwaru?
• Testování stahování e-knih Primer