Výukový program pro správu testů: konečný průvodce pro správu testů

Toto je výukový program pro správu testů pro testování softwaru. Zahrnuje fáze správy testů, Nástroje a správu testů Vs organizační struktura:

Správa testů je proces správy všech činností, dokumentů a dalších souvisejících prací souvisejících s testy. Organizační struktury odkazují na hierarchii týmů nebo zaměstnanců pracujících na konkrétních projektech.

myslíte si, že organizační struktura ovlivňuje řízení testů?

pokud je vaše odpověď Ne, uvidíme proč? Pokud ano, uvidíme, jak to ovlivní. Abychom našli vztah mezi těmito dvěma, musíme těmto tématům jasně porozumět a poté prozkoumat vztah mezi řízením testů a organizační strukturou.

Úvod do správy testů

Správa testů znamená řízení celého procesu testování softwaru pro konkrétní projekt. Proces správy testů je aplikován na celý životní cyklus vývoje softwaru. V ideálním případě by tedy měl začít proces správy testů, jakmile začne proces vývoje softwaru.

vedoucí testu měl následující povinnosti-

• vedoucí testu by měl zajistit konzistenci a kvalitu těchto pracovních produktů.
• Spolupracujte s analytikem testů a analytikem technických testů a vyberte a přizpůsobte příslušnou šablonu.
• Spolupracujte s analytikem testů a analytikem technických testů na stanovení standardů těchto produktů, jako jsou úrovně podrobného stupně.
• zkontrolujte pracovní produkty pomocí vhodných technik.

Správa testů komponenty

Správa testů je rozdělena do 5 částí pro lepší pochopení:

1. zkušební dokumentace
2. odhad testu
3. testovací metriky
4. měření průběhu testu
5. metriky pro sledování životního cyklu testování

#1) Zkušební dokumentace

níže jsou uvedeny tři typy zkušební dokumentace:

• testovací politika
• testovací strategie
• Hlavní testovací plán

#1) testovací politika:

• shrnuje hodnotu, kterou organizace pochází z testování.
• definuje zásady testování.
• popisuje, jak vyhodnotit účinnost testování.
• popisuje zkušební proces.
• Určete, jak organizace zlepší testovací proces?

#2) testovací strategie:

• popisuje obecné testovací metodiky, které se používají k řízení projektových a produktových rizik.
• Analytické Strategie: Jako Testování Založené Na Riziku.
• Modelová Strategie: Jako provozní profil, kde testovací tým vyvíjí model založený na skutečných a přijatých situacích prostředí, vstup, a podmínky.
• metodická strategie: kvalitativní charakteristiky, kde testovací tým používá sadu testovacích podmínek, kontrolní seznam nebo sbírku zobecněných logických testů.
• procesní nebo standardně vyhovující techniky: sleduje sadu procesu, jako je SCRUM / Agile.
• reaktivní strategie: použití útoků založených na defektech, jako je průzkumné testování.
• Poradní Strategie: Stejně jako testování zaměřené na uživatele, kdy testovací tým spoléhá na vstup jedné nebo více zúčastněných stran, aby určil testovací podmínky, jako je externí testování kompatibility.
• také popisuje:
  • integrační postupy
  • techniky SPECIFIKACE testu
  • nezávislost testování
  • povinné a volitelné standardy
  • testovací prostředí
  • nástroje
  • opětovná použitelnost softwarových produktů
  • opakované testování a regrese.

#3) Hlavní Testovací Plán:

• pokrývá všechny testovací úkoly, které je třeba provést.
• pojednává o tom, jak testování implementuje testovací strategii a politiku.
• pokud něco není popsáno, měl by testovací plán popsat proč a plán zmírnění.
• obsah zkušebního plánu je:
  • položky, které mají být zkoušeny
  • vlastnosti jakosti, které mají být zkoušeny.
  • plán
  • prováděcí cyklus
  • defektní proměnné
  • testovací položky v rozsahu
  • výstupní kritéria
  • rizika projektu
  • celková správa testovacích snah,
  • role a odpovědnosti
  • vstup a výstup

#2) odhad testu

obecné body:

• je řídící činnost
• je založena na zkušenostech.
• poskytuje konkrétní a podrobný katalog nákladů, zdrojů, úkolů a lidí.
• odhad jakmile je připraven, musí být dodán vedení spolu s odůvodněním.
• konečný odhad představuje nejlepší možnou rovnováhu mezi organizačními a projektovými cíli.
• odhad vychází z informací dostupných v době, kdy byl připraven.
• aby byly odhady přesné, měly by být aktualizovány tak, aby odrážely nové a změněné informace.

faktory ovlivňující odhad testu:

• požadovaná úroveň kvality
• Velikost systému
• Historická data
• procesní faktory jako strategie, vývoj a životní cyklus
• materiálové faktory jako testovací prostředí, automatizace, nástroje a data
• People factor
• složitost procesu
• školení a KT(přenos znalostí)
• asimilace a vývoj nových nástrojů a technologií, procesů nebo technik.
• požadavek vyššího stupně podrobné specifikace zkoušky.
• načasování příchodu komponenty
• testovací data.

odhady:

• struktura rozdělení práce
• relace odhadu týmu
• poměr Tester-vývojář
• historie organizace
• analýza funkčních bodů, LOC.

odhad testu je dále vysvětlen v tutoriálu.

#3) testovací metriky

• co se měří, je považováno za hotové?
• co se neměří, lze snadno ignorovat?
• je třeba definovat omezenou sadu užitečných metrik.
• měly by být definovány pouze ty metriky, na jejichž interpretaci se všichni shodnou.
• vykazování a slučování metrik by mělo být automatizováno.
• Správce by měl ověřit informace v metrice.

metrika projektu: % průchodu, selhání atd.

metrika produktu:

• atributy produktu
• hustota defektů

metrika procesu: měří schopnost testování jako % vady.

lidé: schopnost jednotlivce.

Metrika Průběhu Testu:

• počet zkušebních podmínek / případů, plánovaných vs provedených.
• celková vada kategorizována podle závažnosti, priority, aktuálního stavu a efektu subsystému.
• počet změn požadovaných, přijatých, sestavených a testovaných.
• plánované vs skutečné náklady.
• plánované vs skutečné trvání
• plánované vs skutečný mezník testování.
• stav rizika kvality produktu
• % ztráta zkušebního úsilí, nákladů nebo času.

#4) měření průběhu zkoušky

rizika produktu:

• % krytí rizika.
• % rizika selhání testu
• % rizika zjištěného jednotlivcem.

vady:

• počet zjištěných vad vs počet předložených vad.
• střední doba výskytu poruch
• závady v jednotlivých testovaných položkách.
• detekce RCA (analýza kořenové příčiny)
• vadou jsou zkušební verze.
• defekt ve fázi
• priorita a závažnost
• Report Rejects vs Duplicate
• čas potřebný k vyřešení
• počet nových defektů zavedených v důsledku stanovení starých defektů.

Test:

• celkový počet testovacího průchodu, selhání, běžec, blokován
• celkový počet případů regresních testů.

pokrytí:

• pokrytí požadavků a návrhu
• pokrytí rizik
• pokrytí konfigurace prostředí
• pokrytí kódu

#5) metriky pro monitorování životního cyklu testování

Monitor testovací plán

• počet rizik a požadavků
• zjištění závad
• plán vs skutečné úsilí.

Monitor Test Design

• počet závad zjištěných během návrhu.

analýza testu monitoru

• počet podmínek
• počet defektů v analýze

implementace testu monitoru

• % konfigurace prostředí
• % testovacího případu automatizované.

provedení monitoru

• % testovacích případů
• % testovacích případů zahrnutých
• plánované vs skutečné vady vyřešeny
• % plánu vs skutečné pokrytí

uzavření monitoru

• % z testovacích případů projít, ail
• % zkušebních případů kontrolovány do opakovaně použitelné Kategorie
• % zkušebních případů automatizovaných.
• počet závad vyřešených/nevyřešených.
• % zkušebního pracovního produktu

níže popsaná fáze monitorování a kontroly testů dále vysvětluje toto téma.

fáze řízení testů

během procesu řízení testů je třeba vzít v úvahu následující body. Jinými slovy, následující jsou různé fáze procesu řízení testů:

1. analýza rizik
2. odhad testu
3. plánování testů
4. organizace testů
5. monitorování a řízení testů
6. Správa problémů
7. zpráva o zkoušce

můžete si všimnout, že první čtyři fáze jsou více o plánování a zbývající tři jsou o provedení. Proto můžeme celý proces řízení testů rozdělit na dvě části, tj.

podívejme se podrobně na různé fáze správy testů.

#1) Analýza rizik

tato fáze zahrnuje zjištění rizikových faktorů a možných řešení. Pokud je analýza rizik provedena důkladně, můžeme se vyhnout budoucím selháním nebo by mohlo být k dispozici alespoň nějaké řešení.

riziko je něco, co se může nebo nemusí stát. Ale pokud se to stane, jaký bude jeho dopad? Může to mít špatný vliv na kvalitu softwaru, pověst společnosti a mnoho dalšího.

je třeba zjistit rizikové faktory, aby se zabránilo tomuto špatnému dopadu. Pro zjištění rizikových faktorů by měla být provedena analýza rizik. Existují dva typy rizik, tj. Rizika projektu a rizika produktu. Rizika projektu jsou rizika, která souvisejí s pracovním procesem a riziko produktu jsou rizika, která souvisejí s vyvinutým produktem.

#2) odhad testu

odhad testu je o predikci času potřebného pro každou testovací aktivitu/fázi. Protože se jedná o odhad, nemůže být přesný. Pro lepší odhad testů můžeme studovat minulé projekty naší společnosti nebo můžeme konzultovat s členy týmu, kteří budou zodpovědní za tuto pracovní nebo zkušební fázi.

#3) plánování testů

samotné plánování testů je dlouhý proces. Zahrnuje definování cílů testu, rozsah testu, testovací strategii, časové plánování, zdroje, komunikační přístup atd. Požadavky by měly být velmi jasné pro definování cílů a rozsahu zkoušek. Testovací plán je určen pro testery, uživatele a členy projektového týmu.

testovací plán popisuje roli testování v projektu. Testovací plán zahrnuje také role a odpovědnosti, seznam funkcí, které budou testovány a nebudou testovány, testovací prostředí, seznam nástrojů a předpokladů, pokud existují.

#4) organizace testů

během fáze plánování testů jsme naplánovali všechny možné věci týkající se testování.

proto potřebujeme kvalifikované členy týmu k provedení tohoto plánu nebo k tomu, aby byl plán úspěšný. Testovací organizace je o budování dokonalého testovacího týmu pro úspěšný projekt.

#5) monitorování a kontrola testů

během testování nebo během testování testerů musí být sledován veškerý tento postup práce. Člověk by měl sledovat všechny tyto testovací práce. Pokud se provádí monitorování testů, pak testovací tým a manažer testů získají zpětnou vazbu o tom, jak probíhá testování?

pomocí této zpětné vazby může manažer testu vést členy týmu ke zlepšení kvality další testovací práce. S pomocí monitorování testů se projektový tým zviditelní na výsledcích testů. Pomáhá také vědět o pokrytí testem.

u velkých projektů se monitorování testů provádí pomocí automatizovaného nástroje, protože shromažďování dat bude snazší. U malých projektů shromáždí jedna osoba všechna data nebo dokumenty, které souvisejí s průběhem testů. Pro shromažďování informací o průběhu testu můžeme použít šablonu protokolu testů IEEE 829. Jednalo se o monitorování testů.

podívejme se, co je kontrola testu? Projektové práce nebudou vždy probíhat tak, jak jsme plánovali. Mohou existovat určité rozdíly mezi plánem a skutečnou prací. Abychom tyto rozdíly minimalizovali nebo odstranili, musíme provést některé změny, a tak kontrolujeme testovací práci.

#6) Správa problémů

problémy mohou být jakýkoli problém, ke kterému dojde během procesu vývoje a testování softwaru. Může to být nejmenší důvod, kvůli kterému nejsme schopni vyvinout / dodat kvalitní produkt. Některé problémy jsou show-stopper tj bez vyřešení tohoto problému nebudeme moci pokračovat v dalším procesu.

Správa problémů je o tom, jak tyto problémy/problémy řešíme. Můžeme to také nazvat jako řízení incidentů. Správa problémů vyžaduje lepší plánování procesu řešení problémů. Lepší správa problémů závisí na dovednostech a zkušenostech manažera testování.

jak se tyto problémy vyskytují?

existuje několik důvodů, proč k problému dojde. Některé problémy se týkají strategie a některé se týkají definice, HR, plánování atd.

strategické problémy:

příklady:

• Projekt vyčerpá finanční prostředky.
• špatná komunikace projektu.
• proces řízení projektu není v souladu s uvedenými standardy.

problémy s definicemi: problémy související s požadavky.

příklady: nejasné požadavky. Mnoho otázek může být zavedeno kvůli nejasným požadavkům.

problémy s plánováním: Toto je nejběžnější typ problému. Zaměstnanci se musí snažit dodržet termín.

HR problémy:

příklady:

• v týmu je nedostatek dovedností.
• nesprávné mapování zaměstnanců pro práci.

tam může být mnohem více typů problémů a nemůžeme zmínit všechny z nich zde. Správa problémů je tedy o protokolování, sledování a řešení problémů.

#7) zpráva o zkoušce

zpráva o zkoušce pomáhá identifikovat pokrytí testu, kvalitu vyvinutého produktu a požadovaná vylepšení procesu. Můžeme se rozhodnout, kolik testování je zapotřebí ?‘

pokud je provedeno dostatečné testování, můžeme tuto zprávu o zkoušce předložit zúčastněným stranám nebo klientům. Aby se také seznámili s kvalitou produktu a měli představu o tom, kolik testování se na produktu provádí.

nástroje pro správu testů

Správa testů se komplikuje, jak postupujeme v procesu vývoje softwaru, a to je jeden z hlavních důvodů, pro které je dnes k dispozici tolik nástrojů pro správu testů.

tyto nástroje pomohou v posledních čtyřech fázích procesu řízení testů (organizace testů, monitorování testů & kontrola, Správa problémů a zpráva o zkoušce). Protože tyto nástroje pomáhají v důležitých fázích řízení testů,měly by být v projektu považovány za první.

Níže jsou uvedeny nejoblíbenější nástroje pro správu testů:

1. qTest
2. Practest
3. Zephyr
4. Test Collab
5. TestFLO pro JIRA
6. XQual
7. Xray – Cutting Edge Test Management
8. TestRail
9. QACoverage
10. požadavky a řízení testů pro Jira (RTM)
11. spiratest by Inflectra
12. Kualitee
13. Aqua
14. Testpad
15. JunoOne

=> Klikněte zde pro podrobné recenze nejlepších nástrojů pro správu testů

organizační struktury

podívejme se na různé organizační struktury.

mohou existovat určitá pravidla pro organizační struktury nebo mohou existovat nějaké ideální struktury, ale bez ohledu na to, že každá organizace může mít svou strukturu. Existuje tolik organizačních struktur a každá z nich má své výhody a nevýhody.

zde budeme diskutovat o některých z nich.

nejprve uvidíme nejjednodušší organizační strukturu, která se používá pro malé projekty.

v této struktuře se testeři i programátoři hlásí Správci vývoje.

1. manažer vývoje má dobrou kontrolu nad aktivitami projektu.
2. bude menší možnost komunikační mezery mezi testovacími a vývojovými týmy.
3. také na schůzkách je dobré rozhodnout o termínech pro manažera vývoje, protože má úplné znalosti o testovacích a vývojových pracích.
4. týmová práce bude efektivní, protože minimální vrstvy.

nevýhody této struktury zahrnují:

1. protože neexistuje žádný manažer testování, existuje možnost, že testování bude zvažováno pozdě v projektu.
2. existuje další možnost, že testování bude mít pro projekt menší význam. To může být považováno za pozdní v projektu.

obecně v malých organizacích pro malé projekty se stává, že vývojový tým trvá více času, než bylo uvedeno, a testovací tým musí trpět, tj. testovací tým bude muset produkt otestovat do termínu, aby testovací tým získal méně času na testování produktu.

v této struktuře musí manažer vývoje pro úspěšné dokončení projektu mít na paměti, že jeho cílem není pouze dokončit projekt, ale vyvinout kvalitní software.

druhá nejčastěji používaná organizační struktura:

Jedná se o nejběžnější typ organizační struktury. V této struktuře se testeři hlásí testovacím manažerům a vývojáři se hlásí vývojovému manažerovi. Manažer testu i manažer vývoje se hlásí projektovému manažerovi.

testovací manažer bude zodpovědný za všechny činnosti související s testy a je odpovědností vývojového manažera, aby Software vyvinul. Projektový manažer bude kontrolovat jak testovací, tak vývojové aktivity.

výhody:

• na rozdíl od předchozí struktury zde v této struktuře existují různí manažeři pro testování a vývoj, a proto se oba mohou soustředit na svou práci. Zůstanou oddaní své práci a bude pro ně méně rozptýlení.
• v této struktuře nelze zanedbat testovací činnosti nebo ji nelze považovat za pozdní projekt. To znamená, že testování i vývoj budou mít stejný význam.
• pokud jde o přijímání kritických rozhodnutí, s výhodou má testovací tým nezávislost.

nevýhody:

• existuje možnost komunikační mezery kvůli více úrovním.

řízení testů Vs organizační struktury

organizační struktury přímo ovlivňují řízení testů. Různé organizační struktury mají odlišný dopad na řízení testů, proto se řízení testů liší podle dovedností a zkušeností vedoucího testování a podle pozice vedoucího testování v organizační struktuře.

viděli jsme zde dvě organizační struktury. V první struktuře je manažer vývoje a manažer testování stejná osoba, a proto ovlivňuje správu testů. Vývojový manažer má za cíl vývoj softwaru, a přitom se musí podívat na testovací práci stejně.

tak občas může dávat zaujaté názory. On / ona může jen přehlédnout problém a pokračovat. Tímto způsobem může ovlivnit řízení testů. Nezávislý manažer testů bude schopen poskytnout větší spravedlnost a správa testů bude lepší u nezávislých zkušebních manažerů.

závěr

viděli jsme obě témata, tj. testovací řízení a organizační struktury samostatně a spolu se vztahem mezi těmito dvěma. Můžeme konstatovat, že organizační struktury ovlivňují řízení testů.

při porovnání obou výše uvedených struktur bude ve druhé struktuře zvládnuto řízení testů lépe než první. Důvodem může být vyhrazený Správce testů.

organizační struktury se liší od jedné organizace k druhé. Ačkoli existuje nějaký definovaný proces pro správu testů (nebo týmy mohou používat nástroje pro správu testů), správa testů se bude lišit kvůli různým organizačním strukturám,manažerům testů, dovednostem a zkušenostem testovacího manažera.