Čo sú Test artifacts a test deliverables v softvérovom testovaní?

V korporátnom svete je udržiavanie transparentnosti medzi projektovým tímom a klientmi rovnako dôležité, ako plnenie ich požiadaviek na daný projekt. Vytvára sa mnoho stratégií, aby medzi zainteresovanými stranami a spoločnosťou odovzdávajúcou softvér nevznikla komunikačná medzera. Na udržanie dobrej komunikácie sa prijímajú rôzne opatrenia. Jedným z takýchto opatrení je prezentácia testovacích artefaktov členom tímu a zainteresovaným stranám.

Čo sú Test artifacts, test deliverables?

Testovacie artefakty (test artifacts) sú známe aj ako testovacie výstupy (test deliverables). Predstavujú dokumenty a skripty vytvorené počas testovania softvéru s cieľom zabezpečiť, aby testovaná aplikácia spĺňala požadované normy kvality. Tieto dokumenty pomáhajú zabezpečiť, aby boli zainteresované strany informované o pokroku v projekte.

Existujú rôzne typy testovacích artefaktov, z ktorých každý slúži na špecifický účel. Testovacie plány (test plans), testovacie prípady (test cases) a testovacie skripty (test scripts) patria medzi najbežnejšie testovacie artefakty používané pri testovaní softvéru.

Test Artifacts list – zoznam najpoužívanejších testovacích výstupov

Test Artifacts list je zoznam najpoužívanejších testovacích výstupov

1.     Test Strategy (Stratégia testovania)

Stratégiu testovania spravidla pripravuje manažér testovania alebo projektu na úrovni manažmentu. Je to náčrt dokumentu, ktorý opisuje prístup k testovaniu vývojového cyklu softvéru, ktorý vymenúva, ako dosiahnuť očakávaný výsledok s využitím dostupných zdrojov.

Jednoducho poskytuje jednoduché pochopenie cieľov, nástrojov, techník, infraštruktúry a načasovania testovacích činností, ktoré sa majú vykonať. Používa sa aj na identifikáciu všetkých rizikových faktorov, ktoré môžu vzniknúť počas testovania a vhodných riešení na zníženie alebo zmiernenie rizika.

Testovacia stratégia zahŕňa najmä komponenty ako:

  • ciele a rozsah testovania,
  • formáty dokumentácie,
  • testovacie procesy a techniky,
  • štruktúra tímového reportingu,
  • stratégia komunikácie s klientom.

2.     Test Plan (Plán testovania)

Plán testovania sa často zamieňa so stratégiou testovania. Je to podrobný dokument, ktorý zahŕňa všetky aspekty fázy testovania. Zatiaľ čo stratégia testovania je len náčrtom celého projektu.

Plán testovania opisuje rozsah testovania softvéru, stratégiu testovania, výsledky testovania, riziká, ciele a činnosti. Je to systémový prístup, ktorý sa všeobecne používa pri testovaní softvérových aplikácií. Je to najdôležitejšia a najpodstatnejšia činnosť, ktorá jednoducho zabezpečí, že v základnom pláne bude spočiatku zoznam úloh a míľnikov na sledovanie alebo identifikáciu pokroku projektu.

Plán testovania zahŕňa:

  • rozsah a ciele projektov,
  • zdroje potrebné na dokončenie projektu,
  • typy testovania a prístupy,
  • riziká,
  • vstupné a výstupné body/kritériá,
  • termíny/harmonogramy,
  • požiadavky na hardvér/softvér.

3.     Test Scenario (Testovací scenár)

Testovací scenár sa používa na opis funkčnosti aplikácie, ktorú možno testovať. Používa sa na uistenie sa, či testovanie funkcie alebo softvéru end-to-end funguje správne. Je odvodený od prípadov použitia (use case).

Obsahuje situáciu alebo podmienku v aplikácii, z ktorej možno vytvoriť mnoho testovacích prípadov. Testovací scenár sa nazýva aj testovacia podmienka alebo testovacia možnosť. Do jedného testovacieho scenára sa môže zmestiť jeden alebo viac testovacích prípadov. Vďaka tomu má testovací scenár s testovacími prípadmi vzťah jeden k mnohým (1:N). Jeden testovací scenár zahŕňa niekoľko testovacích prípadov. Testovacie prípady sú vypracované na základe testovacieho scenára na vysokej úrovni.

Zoberme si testovanie zabezpečenej webovej aplikácie, ktorá pozostáva z mnohých webových stránok. Teraz možno za príklad jedného testovacieho scenára považovať „Overenie prihlasovacej stránky“. Tu musí tester overiť všetky objekty (URL, vstup, tlačidlo, akcie, odkazy atď.) a príslušné funkcie v rámci stránky.

Testovací scenár sa používa na opis funkčnosti aplikácie, ktorú možno testovať.

4.     Test Case (Testovací prípad)

Testovacie prípady sú rozšírenou časťou testovacieho scenára, ktorá pomáha pri vykonávaní testovania. Predstavuje podrobný dokument, ktorý opisuje prípady, ktoré pomôžu pri vykonávaní počas testovania. Je to dokument, ktorý pozostáva z názvu testovacieho prípadu, predbežnej podmienky, krokov/podmienok vstupu a očakávaných výsledkov. Vypracovanie testovacích prípadov pomáha aj pri identifikácii a sledovaní problémov alebo otázok v požiadavkách či v návrhu softvérovej aplikácie.

Body, ktoré je potrebné zahrnúť do testovacieho prípadu:

  • Napíš id testovacieho prípadu, t. j. jedinečné identifikačné číslo testovacieho prípadu.
  • Napíš názov testovacieho prípadu.
  • Uveď testovacie dáta.
  • Napíš všetky podrobnosti a popisy týkajúce sa testovacieho prípadu.
  • Píš postup testu v krokoch, aby bol test case jasný a stručný = jednoduchý.
  • Napíš očakávaný výsledok testu a nechaj priestor aj pre skutočný výsledok testu.

Zoberme si napríklad textové pole vo webovej aplikácii, ktoré môže prijímať len čísla od 1 do 999. Každú hodnotu, ktorá nie je z tohto rozsahu, alebo akúkoľvek alfanumerickú hodnotu by mal systém vyradiť. Na správne overenie funkčnosti vstupného poľa by mal tester napísať dva testovacie prípady – jeden s akoukoľvek vstupnou hodnotou v rozsahu 1 – 999 (pozitívny) a druhý so vstupom akýchkoľvek neplatných alfanumerických údajov / akýchkoľvek číselných údajov, ktoré nie sú v rozsahu 1 – 999 (negatívny).

Testovacie prípady sú rozšírenou časťou testovacieho scenára, ktorá pomáha pri vykonávaní testovania.

5.     Traceability Matrix (Matica sledovateľnosti)

Matica sledovateľnosti je matica, ktorá obsahuje tabuľky, ktoré zobrazujú a vysvetľujú vzťahy medzi mnohými požiadavkami a testovacími prípadmi. V rámci testovania softvéru sa sledovanie požiadaviek často používa na prepojenie podrobných požiadaviek a návrhu testov a konečný produkt je známy ako matica sledovateľnosti požiadaviek (Requirement Traceability Matrix – RTM). RTM sa môže použiť na určenie, či sú všetky aktuálne požiadavky projektu overené alebo pokryté prostredníctvom navrhnutých testovacích prípadov.

Niektoré parametre, ktoré sú zahrnuté v matici sledovateľnosti, sú uvedené nižšie:

  • ID požiadavky,
  • typ požiadavky spolu s opisom,
  • stav návrhu testu spolu so stavom vykonania testu,
  • prípady systémových a unit testov.
  1. Documentation (Dokumentácia)

Automatizované nástroje na tvorbu dokumentácie zjednodušujú vytváranie komplexných správ o testovacích činnostiach, ako sú matice sledovateľnosti požiadaviek (RTM), správy o pokroku a metriky chýb.

  1. Defect/Bug report (Správa o chybe)

Existujú nástroje na automatizáciu testovania, ktoré sa integrujú s rôznymi nástrojmi na sledovanie chýb/defektov. Tieto nástroje automaticky vytvoria hlásenie o chybe, keď sa prostredníctvom automatizovaných testovacích prípadov a testovacích scenárov zachytí chyba. Vytvoria sa hlásenia o chybách, v ktorých sa zdokumentuje problém vrátane ich opisu, závažnosti, krokov na reprodukciu a akýchkoľvek podporných informácií. Tieto správy sa používajú na sledovanie a stanovenie priorít pri riešení chýb. Bug Report sa vytvára po vykonaní všetkých testovacích prípadov.

Obsahuje:

  • ID názvu,
  • prostredie,
  • kroky na reprodukciu,
  • očakávaný výsledok,
  • skutočný výsledok.
  • prílohy (snímky obrazovky, videá, text) chyby,
  • závažnosť/prioritu,
  • príjemc

6.     Software Test Report (Správa o testovaní softvéru)

Testovací tím spravidla na záver každej testovacej aktivity rozosiela rôzne správy, aby informoval zainteresované strany alebo zákazníkov o aktualizácii každej fázy. Tieto správy o testovaní sú určené na zdokumentovanie výsledkov testovania definovaných v pláne testovania.

Správa o testovaní softvéru je teda dokument, ktorý opisuje všetky testovacie činnosti. Poskytuje podrobné informácie o stave testovacích prípadov, testovacích súborov alebo testovacích skriptov pre daný rozsah. Testovacie správy sa môžu generovať denne alebo sa môžu generovať po ukončení testovania.

7.     User guide (Používateľská príručka)

Keď je celý softvér vyvinutý a pripravený na nasadenie na trhu, nakoniec sa vytvorí používateľská príručka. Táto príručka je nápomocná koncovým používateľom a poskytuje podrobné informácie o softvéri a jeho používaní.

Dôvody mať alebo nemať testovacie artefakty

Potrebu testovacích artefaktov môže ovplyvniť niekoľko faktorov:

  • Pravidlá spoločnosti: Niektoré odvetvia, ako napríklad letecký priemysel, jadrová energetika alebo zdravotníctvo, sú prísne, pokiaľ ide o testovanie a dokumentáciu. Môžu od nás vyžadovať vypracovanie podrobných správ.
  • Potreby projektu: Ak pracujeme na niečom, čo musí byť super dobré a spoľahlivé, možno budeme musieť vytvoriť viac testovacích materiálov ako zvyčajne, aby sme sa uistili, že je všetko pokryté.
  • Čo chcú zainteresované strany: Testeri, vývojári, projektoví manažéri a zákazníci môžu mať rôzne predstavy o tom, čo potrebujú od výsledkov testovania. Vývojári môžu potrebovať podrobné správy, aby pochopili a riešili problémy, zatiaľ čo zákazníci môžu chcieť zhrnutie toho, aký dobrý a spoľahlivý je produkt.
  • O čo sa snažíme: Pri rozhodovaní o tom, koľko informácií potrebujeme z výsledkov testovania, zohrávajú úlohu aj ciele testovania. Potrebujeme podrobnejšie a rozsiahlejšie výsledky testovania, aby sme našli a odstránili čo najviac problémov pred vydaním softvéru do produkcie. Ak je však naším cieľom len splnenie základnej úrovne kvality, podrobnejšie výsledky testovania nemusia byť potrebné.
  • Nakoľko je projekt rizikový: Ak ide o vysoko rizikový projekt, môže byť potrebné vytvoriť viac testovacích artefaktov, aby sa systém dôkladne otestoval a zabezpečilo sa, že spĺňa všetky požadované špecifikácie.

Existuje niekoľko dôvodov, prečo organizácia môže potrebovať len niektoré testovacie veci pre projekt. Tu je niekoľko faktorov, ktoré by mohli ovplyvniť toto rozhodnutie:

  • Ako komplikovaný je projekt: Ak ide o pomerne jednoduchý projekt, ktorý má len niekoľko funkcií a nie je v ňom veľa vecí, nemusí byť potrebné vytvoriť všetky testovacie artefakty, ktoré by boli potrebné pre väčší projekt.
  • Aké zdroje sú k dispozícii: Ak má organizácia málo zdrojov, vytváranie všetkých testovacích vecí, ktoré by si potreboval na super komplexné testovanie, nemusí mať zmysel.

Test artifacts v automatizácii testovania

Test artifacts v automatizácii testovania

Poďme sa bližšie venovať jednotlivým typom testovacích artefaktov a preskúmajme, ako môžu využiť automatizáciu:

  1. Stratégia testovania: Stratégia testovania načrtáva celkový prístup a ciele testovania softvérového produktu alebo systému. Táto stratégia testovania môže podrobne opísať proces automatizácie testovania, ktorý sa potom môže uviesť do praxe.
  2. Plán testovania: Plán testovania poskytuje podrobný plán vykonávania testov vrátane rozsahu, zdrojov, časového harmonogramu a vstupných/výstupných kritérií. Nástroje na automatizáciu môžu pomôcť pri vytváraní plánov testov automatickým vyplnením príslušných informácií na základe parametrov projektu.
  3. Testovací scenár: Testovací scenár definuje konkrétnu situáciu alebo udalosť, ktorú je potrebné otestovať v rámci aplikácie alebo systému. Za určitých podmienok sa odporúča, aby sa tieto testovacie scenáre vytvárali a vykonávali pomocou nástrojov na automatizáciu testovania. Práve vtedy by automatizácia týchto testov mohla z dlhodobého hľadiska pomôcť generovať návratnosť investícií.
  4. Testovacie prípady: Testovacie prípady sú podrobné inštrukcie špecifikujúce vstupy, očakávané výstupy, predbežné a následné podmienky na vykonanie testov konkrétnych funkcií alebo komponentov aplikácie. Podobne ako pri testovacích scenároch existujú určité podmienky, kedy sa odporúča tieto testovacie prípady automatizovať pomocou nástrojov na automatizáciu testov.
  5. Testovacie údaje: Testovacie údaje zahŕňajú všetky vstupy potrebné na efektívne vykonanie testov. Tieto testovacie údaje sú užitočné aj pri automatizácii testovacích prípadov a testovacích scenárov.
  6. Dokumentácia: Nástroje na automatizované vytváranie dokumentácie zjednodušujú vytváranie komplexných správ o testovacích činnostiach, ako sú matice sledovateľnosti požiadaviek (RTM), správy o pokroku a metriky chýb.
  7. Správa o chybách/defektoch: Existujú nástroje na automatizáciu testovania, ktoré sa integrujú s rôznymi nástrojmi na sledovanie chýb/defektov. Tieto nástroje automaticky vytvoria správu o chybe, keď sa prostredníctvom automatizovaných testovacích prípadov a testovacích scenárov zachytí chyba.
  8. Správa o testovaní softvéru: Súhrnné správy poskytujú prehľad o celkovom priebehu testovania a kľúčových ukazovateľoch, ako je pokrytie testov, miera úspešnosti/neúspešnosti a trendy defektov. Existujú nástroje na automatizáciu testovania, ktoré tieto súhrnné správy generujú automaticky pre vykonané testy.

Zhrnutie

Na záver možno povedať, že na zabezpečenie kvality produktu je niekedy nevyhnutné vytvoriť všetky testovacie artefakty.

Tieto testovacie artefakty sú potrebné na dôkladný proces testovania, ale je tiež dôležité stanoviť priority a sústrediť sa na najvýznamnejšie a najdôležitejšie artefakty.

Ak si IT tester alebo automatizovaný tester a vieš po nemecky, pozri si naše firemné benefity a reaguj na pracovné ponuky.

O autorovi

Michaela Kojnoková

Agile Test Engineer

Po štúdiu informatiky na ŽU a TUKE som sa najviac ponorila do oblasti automatizácie testovania. Okrem toho sa venujem tvorbe webov, databázam, dátovej analytike, umelej inteligencii a strojovému učeniu. Mám rada cestovanie, šport a najviac si užívam čas strávený v prírode s mojimi blízkymi. LinkedIn

Daj nám o sebe vedieť