13. diel - Testovacie nástroje Nové

V predchádzajúcej lekcii, Manažment rizík, sme sa detailnejšie zamerali na definíciu rizika a jeho atribúty, rozlíšili sme si projektové a produktové riziká a tiež sme si ukázali, čo je to analýza a riadenie produktových rizík. V druhej časti sme sa zamerali na metriky používané v testovaní a taktiež na účel, obsah a cieľové skupiny reportov z testovania.

V dnešnej lekcii, ktorá sa venuje testovacím nástrojom, sa najprv pozrieme na konfiguračný manažment a manažment defektov. Vysvetlíme si, ako rôzne typy testovacích nástrojov podporujú testovanie, a ukážeme si výhody aj riziká automatizácie testov.

Konfiguračný manažment

Konfiguračný manažment je disciplína v oblasti testovania zameraná na identifikáciu, riadenie a sledovanie pracovných produktov:

Konfiguračné položky - Testovanie softvéru podľa ISTQB

Komplexné konfiguračné položky môžu zahŕňať položky čiastkové s definovanými vzťahmi a verziami. Akonáhle je konfiguračná položka schválená, stáva sa súčasťou tzv. baseline a akékoľvek zmeny môžu byť vykonávané iba prostredníctvom formálneho procesu riadenia zmien. Baseline je predvolený stav projektu, kódu alebo systému, ktorý slúži ako referenčný bod pre porovnanie budúcich zmien. Umožňuje merať odchýlky a zaisťuje kontrolu nad zmenami počas vývoja a testovania.

Pri vytvorení novej baseline konfiguračný manažment zaznamenáva všetky zmeny, čo umožňuje reprodukovať predchádzajúce výsledky testov návratom k pôvodnej baseline.

Konfiguračný manažment zaisťuje:

  • jednoznačnú identifikáciu všetkých konfiguračných položiek a ich verzií, evidenciu zmien a sledovanie vzťahov medzi položkami pre trasovateľnosť v priebehu testovania,
  • jednoznačné odkazy na všetky dokumenty a softvérové položky v dokumentácii testovania.

Automatizovaný konfiguračný manažment je často súčasťou DevOps pipeline, ktorá zahŕňa procesy ako continuous integration, continuous delivery a nasadzovanie spolu s automatizovaným testovaním.

Praktický príklad

Predstavme si tím, ktorý testuje nový modul pre správu objednávok v e-shope. Tím vytvára a spravuje niekoľko konfiguračných položiek pre testovanie modulu objednávok. Testovací tím vytvorí test casy na overenie funkčnosti, ako je pridanie položiek do košíka, uplatnenie zliav a dokončenie objednávky. Každý test case je jednoznačne identifikovaný verziou a je uložený v nástroji pre správu verzií. Hneď ako sú všetky test casy schválené, stanú sa súčasťou baseline. Ak je nutné niektorý z test casov upraviť, napríklad pri pridaní novej funkcie, úpravy môžu byť vykonané iba prostredníctvom formálneho procesu riadenia zmien.

Konfiguračný manažment zaznamenáva všetky zmeny vykonané v test casoch a testovacích skriptoch. To umožňuje tímu ľahko sa vrátiť k predchádzajúcej verzii testovacej sady, ak je potrebné reprodukovať výsledky testov z predchádzajúceho cyklu. Automatizovaný konfiguračný manažment je integrovaný do DevOps pipeline. Pri každom nasadení novej verzie modulu sú všetky zmeny v testovacích skriptoch a konfiguráciách automaticky zaznamenané a testy sú spustené, aby sa overilo, že nová verzia neporušila žiadnu z funkcionalít.

Manažment defektov

Management defektov je nevyhnutný proces v testovaní, ktorého cieľom je efektívne riadiť zistené defekty od ich odhalenia až po uzavretie. Tento proces zahŕňa definíciu pracovného postupu pre spracovanie anomálií a pravidlá pre ich klasifikáciu. Pracovný postup obvykle zahŕňa činnosti ako zaznamenávanie, analýzu, klasifikáciu, rozhodnutie o reakcii a uzavretie reportu o defekte. Anomálie môžu byť hlásené v akejkoľvek fáze SDLC, vrátane static testingu. Nie všetky nahlásené anomálie sú skutočné defekty, čo je posúdené v rámci spracovania reportu:

Ciele reportov o defekte - Testovanie softvéru podľa ISTQB

Report o defekte zaznamenaný počas dynamic testingu obvykle obsahuje:

  • jedinečný identifikátor,
  • názov a krátke zhrnutie anomálie,
  • dátum, názov reportujúcej organizácie a meno autora,
  • identifikáciu testovaného objektu a prostredia,
  • kontext defektu,
  • popis zlyhania umožňujúci reprodukciu a vyriešenie,
  • očakávané a skutočné výsledky,
  • závažnosť defektu,
  • prioritu opravy,
  • stav defektu,
  • odkazy.

Praktický príklad

Počas testovania e-shopu môže tester objaviť chybu, kedy sa nesprávne počíta celková cena objednávky pri použití kupónu na zľavu. Tester túto chybu zaznamená do systému pre správu defektov s podrobným popisom problému, identifikáciou testovaného prostredia, krokov k reprodukcii chyby a očakávaného či skutočného výsledku. Defekt je klasifikovaný ako vysoko závažný, pretože ovplyvňuje výpočet platieb zákazníkov, a je prioritne odovzdaný vývojovému tímu na opravu.

Nástroje pre manažment defektov môžu automaticky zaznamenávať niektoré informácie. Šablóny a príklady reportov možno nájsť v norme ISO/IEC/IEEE 29119-3.

Nástroje na podporu testovania

Testovacie nástroje podporujú a uľahčujú mnoho testovacích aktivít. Patria medzi ne napríklad nástroje pre manažment testovania, ktoré zvyšujú efektivitu práce zjednodušením správy SDLC, požiadaviek, testov, defektov a konfigurácií. Nástroje pre static testing zase podporujú vykonávanie revízií a static analysis. Nástroje pre návrh a test implementation uľahčujú vytváranie test casov, testovacích dát a testovacích procedúr. Nájdeme aj nástroje, ktoré napomáhajú automatizovanému vykonávaniu testov a meraniu pokrytia. Ďalšie nástroje zase umožňujú vykonávať nefunkcionálne testovanie, ktoré je ťažké alebo nemožné vykonať manuálne. DevOps nástroje podporujú pipeline v DevOps, sledovanie pracovných tokov, procesy automatizovaného zostavovania a CI/CD.

DevOps - Testovanie softvéru podľa ISTQB

Nástroje pre spoluprácu zlepšujú komunikáciu. Máme tiež nástroje podporujúce škálovateľnosť a štandardizáciu nasadenia, ako virtuálne počítače a nástroje pre prácu s kontajnermi. Môže to byť však aj akýkoľvek iný nástroj, ktorý pomáha pri testovaní, napríklad tabuľkový procesor môže byť v kontexte testovania považovaný za testovací nástroj.

Výhody a riziká automatizácie testov

Jednoduché obstaranie nástroja nie je zárukou úspechu. Každý nový nástroj vyžaduje určitú prácnosť na dosiahnutie reálnych a trvalých prínosov, a to napríklad na zavedenie nástroja, jeho údržbu či školenie. Existujú aj určité riziká, pri ktorých je vhodné vykonať analýzu a zmiernenie ich dopadu.

Medzi možné výhody použitia automatizácie testov patria:

  • Úspora času znížením množstva opakovanej manuálnej práce – patrí sem vykonávanie regression testov, opätovné zadávanie rovnakých testovacích dát, porovnávanie očakávaných výsledkov so skutočnými alebo kontroly kódu podľa daného štandardu programovania.
  • Predchádzanie ľudským chybám vďaka vyššej konzistencii a opakovateľnosti – testy sú dôsledne odvodzované z požiadaviek, testovacie dáta sú vytvárané systematicky a testy sú vykonávané nástrojom v stále rovnakom poradí s rovnakou frekvenciou.
  • Objektívnejšie posúdenie a vykonávanie opatrení, ktoré sú pre človeka príliš komplikované na odvodenie.
  • Jednoduchší prístup k informáciám o testovaní pre podporu manažmentu a reportovania – štatistiky, grafy a súhrnné dáta o priebehu a dĺžke vykonávania testov a miere defektov.
  • Skrátenie doby testovania vedúce k skoršej detekcii defektov, rýchlejšej spätnej väzbe a rýchlejšiemu uvedeniu na trh.
  • Úspora času testerov, ktorý je možné využiť na návrh nových, dôkladnejších a efektívnejších testov.

Medzi možné riziká použitia automatizácie testov patria:

  • Nerealistické očakávania od daného nástroja vrátane funkcionality a jednoduchosti použitia.
  • Nepresné odhady času, nákladov, úsilia potrebného na zavedenie nástroja, udržiavanie testovacích skriptov a zmene existujúceho procesu manuálneho testovania.
  • Používanie nástroja v situáciách, kedy je manuálne testovanie vhodnejšie.
  • Prílišné spoliehanie sa na nástroj, napr. v zmysle ignorovania potreby kritického myslenia človeka.
  • Závislosť na dodávateľovi nástroja, ktorý môže ukončiť činnosť, prestať nástroj vyvíjať, predať ho inému dodávateľovi alebo poskytovať nedostatočnú podporu, napríklad reakcie na otázky, upgrady či opravy defektov.
  • Používanie open-source nástroja, ktorého vývoj môže byť zastavený alebo ktorého vnútorné komponenty môžu vyžadovať pomerne časté aktualizácie a ďalší vývoj.
  • Nekompatibilita technológie automatizácie testovania s technológiami pre vývoj.
  • Výber nevhodného nástroja, ktorý nespĺňa regulatórne požiadavky alebo bezpečnostné normy.

Zdrojom tejto lekcie sú Učebné osnovy – Certifikovaný tester základnej úrovne ver. 4.0. Copyright © 2023 autori verzie 4.0: Renzo Cerquozzi, Wim Decoutere, Klaudia Dussa-Zieger, Jean-François Riverin, Arnika Hryszko, Martin Klonk, Michaël Pilaeten, Meile Posthuma, Stuart Reid, Eric Riou du Cosquer (predseda), Adam Roman, Lucjan Stapp, Stephanie Ulrich (podpredseda), Eshraka Zakaria

V nasledujúcom kvíze, Kvíz - Prístupy k testovaniu, manažment testovania a rizík, si vyskúšame nadobudnuté skúsenosti z predchádzajúcich lekcií.


 

Ako sa ti páči článok?
Pred uložením hodnotenia, popíš prosím autorovi, čo je zleZnakov 0 z 50-500
Predchádzajúci článok
Manažment rizík
Všetky články v sekcii
Testovanie softvéru podľa ISTQB
Preskočiť článok
(neodporúčame)
Kvíz - Prístupy k testovaniu, manažment testovania a rizík
Článok pre vás napísala Jana Zimčíková
Avatar
Užívateľské hodnotenie:
Ešte nikto nehodnotil, buď prvý!
Autorka se věnuje IT a technologiím. Ovládá Javu, Spring Boot, SQL i frontend a chce pomáhat lidem objevit svůj potenciál v IT světě.
Aktivity