Co je analýza dopadu při testování softwaru?

what is impact analysis software testing

Tento výukový program vysvětluje, co je analýza dopadů, výhody, jak ji provádět a jak připravit dokument analýzy dopadů:

Jak víme, technologie má pozitivní i negativní dopad na společnost. Každá jednoduchá změna může mít dopad na tento systém. I velmi malá změna může mít obrovský dopad na systém.

V tomto kurzu podrobně porozumíme analýze dopadů a uvidíme také některé kroky k přípravě dokumentů analýzy dopadů.

Pochopme důležitost této analýzy pomocí diagramu ER (Entity Relationship).

Co se naučíte:

• Důležitost analýzy dopadů
  • Co je analýza dopadu?
  • Jak provést účinnou analýzu dopadů?
  • Jak je metoda dopadové analýzy užitečná pro vývojáře?
  • Jak je metoda dopadové analýzy užitečná pro testery?
  • Jak připravit dokument o analýze dopadů?
  • Výhody nárazové analýzy při testování
• Závěr
  • Doporučené čtení

Důležitost analýzy dopadů

Zvažte diagram ER systému správy obchodů. Chceme tento diagram datového modelu upravit přejmenováním modulu „Položka“ na „Produkt“. Z obr. Č. 01 vidíme, že modul „Item“ je ve vztahu k mnoha dalším modulům. Pokud tedy přejmenujeme modul „Položka“, nevyhnutelně to ovlivní další moduly.

Obr. Č. 01: Systém správy obchodního domu

Před provedením těchto změn tedy musíme dobře analyzovat datový model a dopad změn. V případech, kdy dotyční lidé pečlivě nemyslí na důsledky změn, kterých se v modulech dopustí, může to ovlivnit řádné fungování samotné aplikace. Proto je analýza dopadu velmi důležitá.

Poznámka: Tato analýza ukáže neočekávané chování a všechny vedlejší účinky aplikace.

Co je analýza dopadu?

Zahrnuje analýzu dopadu změn provedených ve funkcích / modulech v aplikaci. Lze to provést téměř ve všech fázích životního cyklu vývoje softwaru, jako jsou požadavky na projekt, návrh systému, kódování, testování atd.

• Analýza modulů pomocí dokumentů dopadové analýzy. Najde rizika spojená s jakýmkoli druhem změn v modulu / produktu.
• Pomáhá při odhadu týmového úsilí potřebného k provedení změn v systému.
• Pomáhá také implementovat prototyp, aby vývojáři a testeři mohli vyzkoušet účinky v systému.

Jak provést účinnou analýzu dopadů?

Níže jsou uvedeny kroky provedené při provádění analýzy projektu:

1. Připravte tým.
2. Zkontrolujte moduly na vysoké úrovni.
3. Zkontrolujte nízkoúrovňové moduly.
4. Vyhodnoťte dopad.
5. Spravujte negativní důsledky.

Krok 1Připravte tým

Před provedením jakýchkoli změn modulů v aplikaci musíme mít tým. Členové týmu by měli mít přístup ke všem modulům v aplikaci a musí mít důkladné znalosti o navrhovaných změnách.

co dělat se souborem torrentu

Někteří členové týmu nebudou vědět o všech modulech. Ale po implementaci dopadové analýzy budou mít všichni členové důkladnou znalost systému.

Krok 2Zkontrolujte moduly na vysoké úrovni

Členové týmu nejprve analyzují moduly na vysoké úrovni v aplikaci, které mohou být ovlivněny navrhovanými změnami. V tuto chvíli musí mít lepší znalosti o strategii a pravidlech pracovního postupu v modulech.

Krok # 3Zkontrolujte nízkoúrovňové moduly

Po kontrole modulů na vysoké úrovni členové týmu zkontrolují moduly na nízké úrovni a identifikují dopad změn v nich. Členové týmu mohou připravit dokument, který uvádí dopad změn v každém modulu. Mohou použít buď list aplikace Excel, nebo textový dokument.

Krok č. 4Vyhodnoťte dopad

Dokument připravený členy týmu odhalí seznam pozitivních i negativních dopadů provedených změn. S pomocí dokumentu získají členové týmu jasnou představu o výhodách, které mohou v důsledku změny vzniknout, a o problémech, kterým v důsledku změny budou čelit.

Krok # 5Spravujte negativní důsledky

Právě teď budou mít členové týmu přesnou představu o výhodách a nevýhodách změn. Ve výsledku mohou tyto změny po projednání se členy týmu a zúčastněnými stranami buď přijmout, nebo odmítnout.

Testeři mohou provádět regresní testování. Regresní testování pomáhá rozpoznat problémy mezi moduly, které vznikly v důsledku dopadu změn v nich.

Jak je metoda dopadové analýzy užitečná pro vývojáře?

V projektu se někdy může změnit požadavek předložený klientem, a to i po zahájení vývojových procesů. Vývojáři možná udělali nějaké kódování. Později kvůli změnám v požadavku musí změnit své kódy. Vývojáři tedy upravují kódy podle požadavků a provádějí změny.

Do procesu vývoje může být zapojen více než jeden vývojář. V některých situacích je extrémně obtížné sledovat dopad změn v různých modulech, protože kódy zadává více než jeden vývojář.

Developer „A“ si nemusí být vědom pracovního postupu v jiném modulu, který zpracovává Developer „B“. Takže i když testování provádějí vývojáři, některé moduly a funkce zůstanou „netestovány“. Vývojáři také potřebovali dobré sledování sdílených zdrojů.

V takových situacích můžeme před provedením jakýchkoli změn v modulech provést schůzky s analýzou dopadu softwaru. Po schůzce členové týmu připraví dokument Impact Analysis. Musí odrážet nejnovější změny a všechny informace založené na riziku.

Po schůzce budou vývojáři informováni o všech modulech v aplikaci. Na těchto setkáních jsou brány v úvahu názory každého člena týmu.

Před provedením jakýchkoli změn vývojáři zváží celou aplikaci / finální produkt. Testování prováděné vývojáři bude lepší. Tím se sníží riziko výskytu chyb v konečné fázi vývoje.

Poznámka: Dokument Analýza dopadů by měl být udržován aktuální.

Jak je metoda dopadové analýzy užitečná pro testery?

Komunikace mezi vývojáři a testery je velmi důležitá. Někdy testeři nebudou dostávat oznámení o změnách v požadavku a budou pokračovat v procesu testování bez jakýchkoli informací o změnách. To je plýtvání časem a zdroji.

Bez metody Impact Analysis zůstanou nové funkce v aplikaci „netestovány“. Pokud testeři vědí o nových funkcích přidaných do aplikace, mohou zahájit regresní testování.

Po analýze začnou testeři vytvářet nebo upravovat testovací případy podle změn v požadavku nebo nových funkcí přidaných do systému.

Poznámka: Tato analýza pomůže testerům rozhodnout o oblastech, které se mají zaměřit na testování, a mohou upřednostnit testovací případy. Lze tedy zlepšit účinnost testování .

Jak připravit dokument o analýze dopadů?

Všichni účastníci setkání o dopadu přispějí k vytvoření dokumentu analýzy dopadů. Obecně se jedná o soubor aplikace Excel. Může to být také slovní dokument.

Šablona tohoto dokumentu je jako matice. Je to velmi snadné pochopit. Má vysokou čitelnost. Další podrobnosti naleznete v tabulce č. 02.

model životního cyklu v softwarovém inženýrství

Naučme se připravit dokument Impact Analysis. Projekt může obsahovat mnoho modulů, funkcí a funkcí.

Zvažte malý projekt, který má 5 funkcí:

1. Přihlásit se
2. Profil
3. Poštovní schránka
4. Přidat k oblíbeným
5. Odhlásit se

Níže (tabulka č. 02) je uvedena odpovídající tabulka dopadové analýzy tohoto konkrétního projektu.

Zde sloupce představují moduly / funkce, které se změnily, a řádky matice představují moduly / funkce, které byly ovlivněny změnami. Když změna v prvku „A“ ovlivní prvek „B“, vývojáři v tabulce vytvoří značku (); před vydáním tohoto dokumentu testerům.

K prokázání silného vlivu jsme použili ČERVENOU barvu. ŽLUTÁ barva se projevuje mírným vlivem, ZELENÁ barva slabým vlivem. Další podrobnosti naleznete v tabulce č. 03.

Přitom mohou testeři snadno pochopit změny v modulech prohlížením různých barevných kódů v dokumentu. Dokument funguje jako kontrolní seznam pro vývojáře a mohou si ověřit, zda nezmeškal žádný modul a závislosti.

Pokud dojde ke změně ve funkci Přihlášení, bude to mít většinou vliv na samotnou funkci „Přihlášení“. Změny ve funkci Přihlášení mohou mírně ovlivnit funkce „Profil“ a „Odhlásit“. To je v dokumentu Impact Analysis označeno barevnými kódy. Dokument tedy bude vypadat jako tabulka č. 04

Můžeme použít čísla k označení úrovně vlivu právě zobrazené v tabulce č. 05. Tabulka č. 04 tedy může být překreslena jako tabulka č. 06.

V tabulce č. 06 má nejvyšší prioritu funkce Přihlášení (Úroveň vlivu: 03). Funkce profilu (Úroveň vlivu: 02) má střední prioritu. Funkce odhlášení (Úroveň vlivu: 01) má nejnižší prioritu.

Poznámka:

• Čísla uvedená v tabulce jsou velmi užitečná pro tým QA. Mohou snadno upřednostnit testovací případy na základě čísel.
• Některé velké projekty budou mít více úrovní vlivu. Je to uvedeno v následující tabulce. (Podívejte se prosím na tabulku č. 07 pro vaši referenci.)

Jak připravit dokument Impact Analysis pro projekt, který má mnoho funkcí a dílčích funkcí?

Zvažte projekt, který má 20 funkcí a každý hlavní rys tohoto projektu má každý 5 dílčích funkcí. Matice představující dokument Impact Analysis je velmi velká a bude obtížné ji udržovat. Odpovídající tabulka bude vypadat jako tabulka č.08.

Abychom tento problém překonali, můžeme použít speciální tabulku pro reprezentaci modulů a dílčích modulů v dokumentu analýzy dopadů. Viz tabulka č. 09, řádky představují hlavní prvky a sloupce představují dílčí prvky.

Pomocí tohoto dokumentu pro velké projekty mohou vývojáři snadno označit dílčí funkce, které mají dopad kvůli změně hlavní funkce. Čitelnost tohoto dokumentu je ve srovnání s lepšíTabulka č. 09.

Poznámka: Všechny dílčí funkce nebudou mít vliv kvůli změnám v hlavní funkci.

Nyní zvažte další projekt, který má 50 hlavních modulů. Projekt má skupinu vývojářů. Různí vývojáři pracují na různých úkolech projektu (přidávání nových funkcí, opravování chyb, refaktorování atd.).

Změny v projektu můžeme ukázat pomocí dokumentu Impact Analysis. Vývojář zapíše informace o odpovídající změně do tabulky. Viz tabulka č. 10 a tabulka č. 11

Výhody nárazové analýzy při testování

• Přesný: Tento dokument bude vždy poskytovat přesná data týkající se změn modulů / funkcí v aplikaci.
• Zvýšená účinnost při testování: S pomocí tohoto dokumentu mohou testeři plánovat testovací případy efektivněji, protože dokument poskytuje jasné informace o změnách v modulech.
• Synchronizovaná práce: Všichni členové týmu jsou zodpovědní za aktualizaci dokumentu Impact Analysis. Tento dokument musí být aktuální.
• Přesný: Jelikož je dokument snadno čitelný, testeři budou mít jasnou představu o změnách v aplikaci při pohledu na dokument.
• Snížená doba testování: Kromě testování celého systému mohou testeři provádět testování modulů a submodulů, které se změnily. Testeři mohou upřednostňovat a plánovat testovací případy. Tím mohou zkrátit dobu testování.
• Zvýšené pokrytí: Pomocí tohoto dokumentu se testeři ujistí, že zkontrolovali dílčí moduly, které jsou ovlivněny změnami v modulech. Tím se zvýší pokrytí projektu testem.
• Standardizace výsledku testu: Vývojáři a testeři budou používat společný dokument Impact Analysis, který představuje každou změnu v modulu.
• Odpovědnost týmu se zvyšuje: Členové týmu musí tento dokument udržovat aktuální. Každý člen týmu je odpovědný za aktualizaci informací o změnách, které v systému provedl.
• Upřednostněte úkol včas a snadno: Vzhledem k tomu, že dokument poskytuje jasný obrázek o změnách, mohou testeři podle něj upřednostnit testování.
• Jasné znalosti o produktu: S pomocí tohoto dokumentu budou mít vývojáři i testeři představu o všech modulech přítomných v systému.
• Snadná detekce chyb: Detekce chyb je mnohem vylepšena. Dokument pro analýzu dopadů je užitečný pro testování integrace.

Závěr

Projekt lze provést s analýzou dopadu nebo bez ní. Ale viděli jsme výhody dokumentu Impact Analysis z výše uvedeného článku. Zavedením tohoto dokumentu se výrazně zkrátí doba testování. Testeři nemusí ztrácet čas testováním funkcí, které se nezmění.

Se zavedením tohoto dokumentu se výrazně zlepšila komunikace mezi vývojáři a testery, což vede k efektivitě testování. Testeři budou mít lepší představu o celém systému.

Doufáme, že máte jasnou představu o analýze dopadů při testování. Neváhejte se podělit o své komentáře.

Doporučené čtení

• Úloha pomocníka QA při testování softwaru
• Kurz testování softwaru: Ke kterému institutu pro testování softwaru bych se měl připojit?
• Práce na volné noze se softwarem pro testování technického obsahu Writer
• Výběr testování softwaru jako vaší kariéry
• Vyzkoušejte své možnosti analýzy a schopnost přemýšlet - cvičení pro testování softwaru (část 2)
• Zpětná vazba a recenze kurzu testování softwaru
• Některé zajímavé otázky týkající se testování softwaru
• Testuje software emocionální úkol?