Plán testovania je podrobný dokument, ktorý popisuje oblasti a činnosti testovania softvéru. Načrtáva stratégiu testovania, ciele, harmonogram testovania, požadované zdroje (ľudské zdroje, softvér a hardvér), odhad testu a výstupy testov.

Testovací plán je základom testovania každého softvéru. Je to najdôležitejšia činnosť, ktorá zabezpečuje dostupnosť všetkých zoznamov plánovaných činností v správnom poradí.

Testovací plán je šablóna na vykonávanie aktivít testovania softvéru ako definovaný proces, ktorý je plne monitorovaný a kontrolovaný manažérom testovania. Plán testu pripravuje vedúci testu (60 %), manažér testu (20 %) a testovací inžinier (20 %).

Typy testovacieho plánu

Existujú tri typy plánu testovania

• Hlavný testovací plán
• Fázový testovací plán
• Testovacie plány špecifické pre typ testovania

Hlavný testovací plán

Master Test Plan je typ testovacieho plánu, ktorý má viacero úrovní testovania. Zahŕňa kompletnú testovaciu stratégiu.

Fázový testovací plán

Plán fázového testovania je typ plánu testovania, ktorý sa zaoberá ktoroukoľvek fázou testovacej stratégie. Napríklad zoznam nástrojov, zoznam testovacích prípadov atď.

Špecifické testovacie plány

Špecifický testovací plán určený pre hlavné typy testovania, ako je testovanie bezpečnosti, záťažové testovanie, testovanie výkonu atď. Inými slovami, špecifický testovací plán určený pre nefunkčné testovanie.

Ako napísať testovací plán

Vytvorenie plánu testovania je najdôležitejšou úlohou procesu riadenia testov. Podľa IEEE 829 postupujte podľa nasledujúcich siedmich krokov na prípravu plánu testovania.

• Najprv analyzujte štruktúru a architektúru produktu.
• Teraz navrhnite testovaciu stratégiu.
• Definujte všetky ciele testu.
• Definujte oblasť testovania.
• Definujte všetky použiteľné zdroje.
• Naplánujte si všetky aktivity vhodným spôsobom.
• Určite všetky výstupy testu.

Komponenty alebo atribúty testovacieho plánu

Testovací plán sa skladá z rôznych častí, ktoré nám pomáhajú odvodiť celú testovaciu aktivitu.

Ciele: Pozostáva z informácií o moduloch, funkciách, testovacích dátach atď., ktoré označujú cieľ aplikácie, teda správanie aplikácie, cieľ atď.

Rozsah: Obsahuje informácie, ktoré je potrebné otestovať s príslušnou aplikáciou. Rozsah možno ďalej rozdeliť na dve časti:

• V rozsahu
• Mimo rozsah

V rozsahu: Toto sú moduly, ktoré je potrebné dôkladne (podrobne) otestovať.

Mimo rozsah: Toto sú moduly, ktoré nie je potrebné dôsledne testovať.

Napríklad , Predpokladajme, že máme na testovanie aplikáciu Gmail, kde vlastnosti, ktoré sa majú testovať ako napr Písať poštu, Odoslané položky, Doručená pošta, Koncepty a vlastnosti, ktoré neboli testované ako napr Pomoc , a tak ďalej, čo znamená, že vo fáze plánovania rozhodneme o tom, ktorá funkčnosť musí byť skontrolovaná alebo nie na základe časového limitu uvedeného v produkte.

Teraz ako sa rozhodneme, ktoré funkcie sa netestujú?

Máme nasledujúce aspekty, pri ktorých sa môžeme rozhodnúť, ktorá funkcia nebude testovaná:

• Ako vidíme vyššie Pomoc funkcie sa nebudú testovať, pretože ich napísal a vyvinul technický autor a preskúmal iný profesionálny autor.
• Predpokladajme, že máme jednu aplikáciu, ktorá má P, Q, R a S vlastnosti, ktoré je potrebné vyvinúť na základe požiadaviek. Ale tu už bola funkcia S navrhnutá a používaná inou spoločnosťou. Vývojový tím teda kúpi S od tejto spoločnosti a integruje sa s ďalšími funkciami, ako sú P, Q a R.

Teraz nebudeme vykonávať funkčné testovanie funkcie S, pretože už bola použitá v reálnom čase. Urobíme však testovanie integrácie a testovanie systému medzi funkciami P, Q, R a S, pretože nové funkcie nemusia správne fungovať s funkciou S, ako môžeme vidieť na obrázku nižšie:

• Predpokladajme, že v prvom vydaní produktu budú prvky, ktoré boli vyvinuté, ako napr P, Q, R, S, T, U, V, W…..X, Y, Z . Teraz klient poskytne požiadavky na nové funkcie, ktoré zlepšujú produkt v druhom vydaní a nové funkcie sú A1, B2, C3, D4 a E5.

Potom napíšeme rozsah počas plánu testu ako

Rozsah

Vlastnosti na testovanie

A1, B2, C3, D4, E5 (nové funkcie)

P, Q, R, S, T

Vlastnosti, ktoré sa netestujú

zarovnať css obrázok

W…..X, Y, Z

Preto najprv skontrolujeme nové funkcie a potom budeme pokračovať so starými funkciami, pretože to môže byť ovplyvnené po pridaní nových funkcií, čo znamená, že to ovplyvní aj oblasti dopadu, takže urobíme jedno kolo regresného testovania pre P, Q , R…, T funkcie.

Metodika testu:

Obsahuje informácie o vykonávaní iného druhu testovania, ako je funkčné testovanie, testovanie integrácie a testovanie systému atď. v aplikácii. V tomto sa rozhodneme, aký typ testovania; vykonáme rôzne funkcie na základe požiadaviek aplikácie. A tu by sme tiež mali definovať, aký druh testovania použijeme v metodológiách testovania, aby každý, ako vedenie, vývojový tím a testovací tím, ľahko porozumel, pretože podmienky testovania nie sú štandardné.

Napríklad, pre samostatnú aplikáciu ako napr Adobe Photoshop , vykonáme nasledujúce typy testovania:

Testovanie dymom→ Funkčné testovanie → Testovanie integrácie →Testovanie systému →Testovanie adhoc → Testovanie kompatibility → Testovanie regresie→ Testovanie globalizácie → Testovanie dostupnosti → Testovanie použiteľnosti → Testovanie spoľahlivosti → Testovanie obnovy → Testovanie inštalácie alebo odinštalovania

A predpokladajme, že to musíme otestovať https://www.jeevansathi.com/ aplikáciu, preto vykonáme nasledujúce typy testovania:

Prístup

Tento atribút sa používa na opis toku aplikácie pri vykonávaní testovania a pre budúce použitie.

Tok aplikácie môžeme pochopiť pomocou nižšie uvedených aspektov:

Písaním scenárov na vysokej úrovni Napísaním prietokového grafu

Písaním scenárov na vysokej úrovni

Napríklad Predpokladajme, že testujeme Gmail aplikácia:

• Prihláste sa do Gmailu – odošle e-mail a skontrolujte, či je na stránke Odoslané položky
• Prihlásiť sa …….
• ……
• .....

Píšeme to preto, aby sme opísali prístupy, ktoré je potrebné použiť na testovanie produktu a iba pre kritické funkcie, kde budeme písať scenáre na vysokej úrovni. Tu sa nezameriame na pokrytie všetkých scenárov, pretože konkrétny testovací technik môže rozhodnúť o tom, ktoré funkcie je potrebné otestovať alebo nie.

Napísaním prietokového grafu

Vývojový graf je napísaný, pretože písanie scenárov na vysokej úrovni trvá trochu času, ako môžeme vidieť na obrázku nižšie:

Vytvárame vývojové grafy, aby sme získali nasledujúce výhody, ako napríklad:

• Pokrytie je jednoduché
• Zlúčenie je jednoduché

Prístup možno rozdeliť do dvoch častí, ktoré sú nasledovné:

• Prístup zhora nadol
• Prístup zdola nahor

Predpoklad

Obsahuje informácie o probléme alebo probléme, ktorý sa mohol vyskytnúť počas testovacieho procesu a pri písaní testovacích plánov by boli vytvorené zaručené predpoklady ako zdroje a technológie atď.

Riziko

Toto sú výzvy, ktorým musíme čeliť pri testovaní aplikácie v aktuálnom vydaní, a ak predpoklady zlyhajú, sú s tým spojené aj riziká.

Napríklad, účinnosť pre aplikáciu, dátum vydania sa posúva.

plán zmierňovania alebo pohotovostný plán

Ide o záložný plán, ktorý je pripravený na prekonanie rizík alebo problémov.

Pozrime sa na jeden príklad pre predpoklad, riziko a pohotovostný plán spolu, pretože spolu súvisia.

V akomkoľvek produkte, predpoklad urobíme, že všetci 3 testovací inžinieri tam budú až do dokončenia produktu a každému z nich sú priradené rôzne moduly, ako napríklad P, Q a R. V tomto konkrétnom scenári riziko mohlo by to byť, keby skúšobný inžinier opustil projekt uprostred neho.

Preto, pohotovostný plán bude každému objektu priradený primárny a podriadený vlastník. Takže ak jeden testovací technik odíde, podriadený vlastník prevezme túto špecifickú funkciu a tiež pomôže novému testovaciemu technikovi, aby mohol porozumieť ich priradeným modulom.

Predpoklady, riziko a plán na zmiernenie alebo nepredvídané udalosti sú vždy presné na samotnom produkte. Rôzne druhy rizík sú nasledovné:

• Pohľad zákazníka
• Zdrojový prístup
• Technický posudok

Úloha a zodpovednosť

Definuje kompletnú úlohu, ktorú musí vykonať celý testovací tím. Keď príde veľký projekt, potom Správca testov je osoba, ktorá píše plán testovania. Ak existujú 3-4 malé projekty, manažér testovania pridelí každý projekt každému vedúcemu testovania. Vedúci testu potom napíše plán testovania projektu, ktorý je mu pridelený.

Pozrime sa na jeden príklad, v ktorom pochopíme úlohy a zodpovednosť testovacieho manažéra, testovacieho vedúceho a testovacích inžinierov.

odovzdať reťazec do int java

Úloha: manažér testov

Meno: Ryan

Zodpovednosť:

• Pripravte (napíšte a skontrolujte) plán testu
• Vykonajte stretnutie s vývojovým tímom
• Vykonajte stretnutie s testovacím tímom
• Vykonajte stretnutie so zákazníkom
• Zorganizujte jedno mesačné stand up stretnutie
• Poznámka k vydaniu odhlásenia
• Riešenie eskalácií a problémov

Úloha: Vedúci testu

Meno: Harvey

Zodpovednosť:

• Pripravte (napíšte a skontrolujte) plán testu
• Uskutočňujte každodenné stand up stretnutia
• Skontrolujte a schváľte testovací prípad
• Pripravte RTM a správy
• Priraďte moduly
• Harmonogram manipulácie

Úloha: Testovací technik 1, Testovací technik 2 a Testovací technik 3

Meno: Louis, Jessica, Donna

Priraďte moduly: M1, M2 a M3

Zodpovednosť:

• Napíšte, skontrolujte a spustite testovacie dokumenty, ktoré pozostávajú z testovacích prípadov a testovacích scenárov
• Prečítajte si, skontrolujte, pochopte a analyzujte požiadavku
• Napíšte tok aplikácie
• Vykonajte testovací prípad
• RTM pre príslušné moduly
• Sledovanie defektov
• Pripravte správu o vykonaní testu a odovzdajte ju vedúcemu testu.

Rozvrh

Používa sa na vysvetlenie načasovania práce, čo je potrebné urobiť, alebo tento atribút pokrýva, kedy presne by mala každá testovacia aktivita začať a skončiť? A presné údaje sú tiež uvedené pre každú testovaciu aktivitu pre konkrétny dátum.

Preto, ako môžeme vidieť na obrázku nižšie, pre konkrétnu aktivitu bude existovať počiatočný dátum a dátum ukončenia; pre každé testovanie na konkrétnu zostavu bude uvedený dátum.

Napríklad

• Písanie testovacích prípadov
• Proces vykonávania

Sledovanie defektov

Vo všeobecnosti sa to robí pomocou nástrojov, pretože nemôžeme sledovať stav každej chyby manuálne. A tiež sa vyjadrujeme k tomu, ako komunikujeme o chybách, ktoré sú identifikované počas testovacieho procesu a posielame to späť vývojovému tímu a ako odpovie vývojový tím. Tu tiež uvádzame prioritu chýb, ako je vysoká, stredná a nízka.

Nasledujú rôzne aspekty sledovania defektov:

Techniky na sledovanie chyby
…..
……
……
……Nástroje na sledovanie chýb
Môžeme komentovať názov nástroja, ktorý budeme používať na sledovanie chýb. Niektoré z najčastejšie používaných nástrojov na sledovanie chýb sú Jira, Bugzilla, Mantis a Trac atď.<Závažnosť
Závažnosť môže byť nasledovná:
Blocker alebo showstopper
…..
….. (Vysvetlite to príkladom v pláne testu)
Napríklad , bude chyba v module; nemôžeme ísť ďalej a testovať ďalšie moduly, pretože ak je chyba zablokovaná, môžeme pokračovať v kontrole iných modulov.
Kritické
……
….. (Vysvetlite to príkladom v pláne testu)
V tejto situácii budú mať vady vplyv na obchod.
Major
….
…. (Vysvetlite to príkladom v pláne testu)
Menší
…..
….. (Vysvetlite to príkladom v pláne testu)
Tieto chyby sú tie, ktoré ovplyvňujú vzhľad a dojem z aplikácie.Priorita
High-P1
…..
Stredná-P2
…..
Nízke-P3
…..
…..
P4

Preto na základe priority chýb, ako je vysoká, stredná a nízka, ich kategorizujeme ako P1, P2, P3 a P4.

Testovacie prostredia

Toto sú prostredia, v ktorých budeme aplikáciu testovať, a tu máme dva typy prostredí, ktoré sú softvér a hardvér konfigurácia.

The softvérová konfigurácia znamená podrobnosti o rôznych Operačné systémy ako napr Windows, Linux, UNIX a Mac a rôzne Prehliadače Páči sa mi to Google Chrome, Firefox, Opera, Internet Explorer , a tak ďalej.

A hardvérová konfigurácia znamená informácie o rôznych veľkostiach RAM, ROM a procesory .

Napríklad

• The softvér zahŕňa nasledovné:

Server

Poznámka: Vyššie uvedené servery sú servery, ktoré používa testovací tím na testovanie aplikácie.

Zákazník

Poznámka: Vyššie uvedené podrobnosti poskytujú rôzne operačné systémy a prehliadače, v ktorých bude testovací tím testovať aplikáciu.

• The Hardvér zahŕňa nasledovné:

Server : Sun StarCat 1500

Tento konkrétny server môže testovací tím použiť na testovanie svojej aplikácie.

Zákazník:

Má nasledujúcu konfiguráciu, ktorá je nasledovná:

Poznámka: Poskytne konfiguráciu systémov testovacích inžinierov, ktorí sú testovacím tímom.

Proces inštalácie softvéru
……
…..
…..

Vývojový tím poskytne konfiguráciu spôsobu inštalácie softvéru. Ak vývojový tím ešte proces nezabezpečí, potom ho do plánu testovania zapíšeme ako Task-Based Development (TBD).

Vstupné a výstupné kritériá

Je to nevyhnutná podmienka, ktorú je potrebné splniť pred spustením a zastavením procesu testovania.

Vstupné kritériá

Vstupné kritériá obsahujú nasledujúce podmienky:

• Testovanie bielej skrinky by sa malo ukončiť.
• Pochopte a analyzujte požiadavku a pripravte skúšobné dokumenty alebo keď sú skúšobné dokumenty pripravené.
• Testovacie údaje by mali byť pripravené.
• Musí byť pripravená zostava alebo aplikácia
• Moduly alebo funkcie musia byť priradené rôznym testovacím technikom.
• Potrebný zdroj musí byť pripravený.

Výstupné kritériá

Výstupné kritériá obsahujú tieto podmienky:

• Keď sa vykonajú všetky testovacie prípady.
• Väčšina testovacích prípadov musí byť prešiel .
• Závisí od závažnosti chýb, čo znamená, že nesmie existovať žiadny blokátor alebo závažná chyba, zatiaľ čo niektoré menšie chyby existujú.

Než začneme vykonávať funkčné testovanie, všetko vyššie uvedené Vstupné kritériá treba dodržiavať. Potom, čo sme vykonali funkčné testovanie a predtým, ako vykonáme testovanie integrácie, potom Výstupné kritériá z funkčné testovanie by malo nasledovať, pretože o % výstupných kritérií rozhoduje stretnutie s manažérom vývoja a testovania, pretože ich spoluprácou možno dosiahnuť dané percento. Ak však nie sú dodržané výstupné kritériá funkčného testovania, nemôžeme pokračovať v integračnom testovaní.

Tu na základe závažnosti chyby znamená, že testovací tím by sa rozhodol pokračovať v ďalších fázach.

Automatizácia testov

V tomto sa rozhodneme o nasledujúcom:

• Ktorá funkcia musí byť zautomatizovaná a ktorá nie?
• Ktorý nástroj na automatizáciu testov použijeme na ktorom automatizačnom rámci?

Testovací prípad automatizujeme až po prvom vydaní.

Tu vyvstáva otázka, na základe čoho my bude rozhodnúť, ktoré funkcie treba otestovať?

Na obrázku vyššie vidíme, že najčastejšie používané funkcie je potrebné znova a znova testovať. Predpokladajme, že musíme skontrolovať aplikáciu Gmail, kde sú základné funkcie Vytvárajte poštu, odoslanú poštu a doručenú poštu . Takže tieto funkcie otestujeme, pretože pri manuálnom testovaní to zaberie viac času a stáva sa to aj monotónna práca.

teraz ako rozhodneme, ktoré funkcie sa nebudú testovať?

testovanie výkonu

Predpokladajme pomoc funkcia aplikácie Gmail nie je opakovane testovaná, pretože tieto funkcie sa pravidelne nepoužívajú, takže ich nemusíme často kontrolovať.

ale ak sú niektoré funkcie nestabilné a majú veľa chýb , čo znamená, že tieto funkcie nebudeme testovať, pretože sa musia testovať znova a znova pri manuálnom testovaní.

Ak existuje funkcia, ktorú je potrebné často testovať , ale očakávame zmenu požiadaviek pre túto funkciu, takže to nekontrolujeme, pretože zmena manuálnych testovacích prípadov je pohodlnejšia v porovnaní so zmenou v skripte automatizácie.

Odhad úsilia

V tomto budeme plánovať úsilie, ktoré musí vynaložiť každý člen tímu.

Testovacia dodávka

Ide o dokumenty, ktoré sú výstupom z testovacieho tímu, ktorý sme odovzdali zákazníkovi spolu s produktom. Zahŕňa nasledovné:

Testovací plán Testovacie prípady Testovacie skripty RTM (matica sledovateľnosti požiadaviek) Hlásenie o poruche Správa o vykonaní testu Grafy a metriky Poznámky k vydaniu

Grafy a metriky

Graf

V tomto budeme diskutovať o typoch grafov pošleme a poskytneme aj ukážku každého grafu.

Ako vidíme, máme päť rôznych grafov, ktoré zobrazujú rôzne aspekty procesu testovania.

Graf 1: V tomto ukážeme, koľko defektov bolo identifikovaných a koľko defektov bolo opravených v každom module.

Graf 2: Obrázok 1 ukazuje, koľko kritických, veľkých a menších chýb bolo identifikovaných pre každý modul a koľko bolo opravených pre ich príslušné moduly.

Graf 3: V tomto konkrétnom grafe znázorňujeme zostavte múdry graf , čo znamená, že v každej zostave bolo identifikovaných a opravených koľko chýb pre každý modul. Na základe modulu sme určili chyby. Doplníme R ukázať počet defektov v P a Q a tiež pridáme S ukázať chyby v P, Q a R.

Graf 4: Testovací vodič navrhne Analýza trendov chýb graf, ktorý sa vytvára každý mesiac a pošlite ho aj Manažmentu. A je to ako predpoveď, ktorá sa robí na konci produktu. A tu môžeme tiež hodnotiť opravy chýb ako to môžeme pozorovať oblúk má stúpajúca tendencia na obrázku nižšie.

Graf 5: The Správca testov navrhol tento typ grafu. Tento graf je určený na pochopenie medzery v hodnotení chýb a skutočných chýb, ktoré sa vyskytli, a tento graf tiež pomáha zlepšiť hodnotenie chýb v budúcnosti.

Metriky

Ako je uvedené vyššie, vytvoríme graf distribúcie chýb, ktorý je na obrázku 1, a pomocou vyššie uvedených údajov navrhneme aj metriky.

Napríklad

Na obrázku vyššie uchovávame záznamy všetkých testovacích inžinierov v konkrétnom projekte a koľko defektov bolo identifikovaných a opravených. Tieto údaje môžeme použiť aj na budúcu analýzu. Keď príde nová požiadavka, môžeme sa rozhodnúť, komu poskytneme náročnú funkciu na testovanie na základe počtu defektov, ktoré našli skôr podľa vyššie uvedených metrík. A budeme v lepšej situácii, keď budeme vedieť, kto si s problematickými funkciami vie veľmi dobre poradiť a nájsť maximálny počet defektov.

Poznámky k vydaniu: Ide o dokument, ktorý je pripravený počas vydania produktu a podpísaný manažérom testu.

Na obrázku nižšie môžeme vidieť, že finálny produkt je vyvinutý a nasadený zákazníkovi a názov najnovšieho vydania je Beta .

The Poznámky k vydaniu pozostáva z nasledovného:

• Používateľská príručka.
• Zoznam nevybavených a otvorených defektov.
• Zoznam pridaných, upravených a odstránených funkcií.
• Zoznam platformy (operačný systém, hardvér, prehliadače), na ktorej je produkt testovaný.
• Platforma, na ktorej produkt nie je testovaný.
• Zoznam chýb opravených v aktuálnom vydaní a zoznam opravených chýb v predchádzajúcom vydaní.
• Proces inštalácie
• Verzie softvéru

Napríklad

Predpokladajme, že Beta je druhým vydaním aplikácie po prvom vydaní Alfa je prepustený. Niektoré chyby identifikované v prvom vydaní a ktoré boli opravené v neskoršom vydaní. A tu tiež poukážeme na zoznam novo pridaných, upravených a odstránených funkcií od vydania alfa po vydanie beta.

Šablóna

Táto časť obsahuje všetky šablóny pre dokumenty, ktoré budú použité v produkte, a všetci testovací inžinieri použijú v projekte iba tieto šablóny, aby sa zachovala konzistencia produktu. Tu máme rôzne typy šablón, ktoré sa používajú počas celého procesu testovania, ako napríklad:

• Šablóna testovacieho prípadu
• Šablóna kontroly testovacieho prípadu
• RTM šablóna
• Šablóna hlásenia chyby
• Správa o vykonaní testu

Pozrime sa na jednu vzorku dokumentu plánu testovania

Strana-1

Strana3-strana18

Strana-20

Na stránke 1 primárne vypĺňame iba Verzie, autor, komentáre a recenzia poliach a po schválení manažérom uvedieme podrobnosti v Schválené do a dátum schválenia poliach.

Testovací plán väčšinou schvaľuje Test Manager a testovací inžinieri ho iba kontrolujú. A keď prídu nové funkcie, upravíme plán testovania a vykonáme potrebné úpravy Verzia a potom sa znova odošle na ďalšiu kontrolu, aktualizáciu a schválenie manažérovi. Testovací plán sa musí aktualizovať vždy, keď nastanú nejaké zmeny. Na strane 20, Referencie špecifikovať podrobnosti o všetkých dokumentoch, ktoré použijeme na napísanie dokumentu plánu testu.

Poznámka:

Kto píše plán testovania?

• Testovací potenciál→60 %
• Správca testov→20 %
• Testovací technik→20 %

Preto, ako môžeme vidieť zhora, v 60 % produktu je plán testu napísaný vedúcim testu.

Kto kontroluje plán testovania?

• Vedúci testu
• Správca testov
• Skúšobný inžinier
• Zákazník
• Vývojový tím

Testovací technik kontroluje plán testovania z hľadiska ich modulovej perspektívy a manažér testu kontroluje plán testovania na základe názoru zákazníka.

Kto schvaľuje plán testovania?

• Zákazník
• Správca testov

Kto píše testovací prípad?

• Vedúci testu
• Skúšobný inžinier

Kto kontroluje testovací prípad?

• Skúšobný inžinier
• Vedúci testu
• Zákazník
• Vývojový tím

Kto schvaľuje testovacie prípady?

• Správca testov
• Vedúci testu
• Zákazník

Pokyny pre plán testov

• Zbaľte svoj testovací plán.
• Vyhnite sa prekrývaniu a nadbytočnosti.
• Ak si myslíte, že nepotrebujete sekciu, ktorá je už spomenutá vyššie, vymažte ju a pokračujte ďalej.
• Byť špecifický. Napríklad, keď zadáte softvérový systém ako súčasť testovacieho prostredia, potom namiesto názvu uveďte verziu softvéru.
• Vyhnite sa dlhým odsekom.
• Všade, kde je to možné, používajte zoznamy a tabuľky.
• Aktualizujte plán podľa potreby.
• Nepoužívajte zastaraný a nepoužitý dokument.

Význam plánu testov

• Testovací plán dáva smer nášmu mysleniu. Je to ako kniha pravidiel, ktorá sa musí dodržiavať.
• Plán testu pomáha pri určovaní potrebného úsilia na overenie kvality testovanej softvérovej aplikácie.
• Plán testovania pomáha týmto ľuďom porozumieť detailom testu, ktoré súvisia s vonkajším prostredím, ako sú vývojári, obchodní manažéri, zákazníci atď.
• Dôležité aspekty, ako je plán testovania, stratégia testovania, rozsah testovania atď., sú zdokumentované v pláne testovania, aby ich manažérsky tím mohol skontrolovať a znova použiť pre iné podobné projekty.