Defect Life Cycle - Ako ste si už mohli byť vedomí, že vykonanie testu je fáza, v ktorej by tester skutočne vykonával testovacie skripty. Proces vykonávania testovacích skriptov sa v jednotlivých spoločnostiach líši a môže sa líšiť v rôznych projektoch v rámci tej istej spoločnosti.
Teraz dni sú k dispozícii nástroje na vykonanie testu, nástroje ako - Centrum kvality, Microsoft Visual Studio a tak ďalej. Skutočný proces vykonávania každého kroku na porovnanie skutočného a očakávaného výsledku zostáva pre funkčného testera rovnaký bez ohľadu na použité nástroje.
- Čo keď sa skutočné správanie nerovná očakávanému správaniu?
Keď tester zistí, že skutočný výsledok testovania sa nerovná očakávanému výsledku, chyba sa zaznamená.
- Ako prihlásiť chybu?
Dnes je k dispozícii veľa nástrojov, niektoré z nástrojov na protokolovanie chýb sú ClearQuest od spoločnosti IBM, HP Quality Center, nástroje s otvoreným zdrojovým kódom, ako je životný cyklus defektov v JIRA atď.
Existujú niektoré povinné polia, ktoré sú spoločné pre rôzne nástroje na zaznamenávanie chýb, tieto polia sú -
- Životný cyklus vady Popis
- Zhrnutie životného cyklu defektu
- Chyba zaznamenaná používateľom
- Chyba priradená
- Závažnosť chyby
- Priorita chyby
- Ďalšie snímky
- Číslo vydania / meno
Porucha životného cyklu
Životný cyklus defektu sa začína zaznamenaním novej chyby. Vždy, keď je chyba zaznamenaná, prejde do stavu „Nový“.
Tester - nová chyba
Koho priradiť novú chybu?
Tester môže priradiť vadu vývojárovi alebo vývojárovi. Toto rozhodnutie o priradení defektov sa líši od projektu k projektu. Na niektorých pracoviskách existuje proces životného cyklu defektov, ktorý sa má priradiť priamo príslušnému vývojárovi, a na niektorých miestach sa defekt najskôr priradí vývojárovi elektródy a vývojový vodič ho následne priradí vývojárovi.
Priradenie defektov (nové) - vývojár defektov životného cyklu
Priradenie chýb (nové) - vývojár Dev Leadà
Analýza defektov
Vývojár analyzuje chybu, aby skontroloval, či je reprodukovateľná. Tu je najdôležitejším prínosom testera zahrnutie všetkých potrebných detailov do defektu. Súhrn defektov, Podrobný popis defektov sú polia, ktoré pomáhajú zúčastneným stranám pochopiť defekt naraz. Súhrn defektov by mal mať vždy len informácie o vysokej úrovni chyby. Zároveň by mala mať dostatok informácií na opis prehľadu chyby na jednom riadku.
Opis chyby je miesto, kde sa od testera očakáva, že bude obsahovať všetky potrebné informácie, ako napríklad prostredie, scenár, použité testovacie údaje, očakávaný výsledok, skutočný výsledok, odkaz na súbory / údaje a odkaz na snímku.
Tu je krátky prehľad rôznych prvkov podrobného popisu defektu -
prostredie
Testujte prostredie, v ktorom bola zistená chyba. Projekty majú často viac testovacích prostredí, v ktorých testovací tím vykonáva testovanie. Napríklad - AT (prostredie testovania zostavy), PT (prostredie testovania produktu), UAT (prostredie testovania akceptácie používateľa) atď. Účelom rôznych prostredí je to, že poskytuje flexibilitu v rámci vývojového a testovacieho tímu, aby bol kód nasadený v ktoromkoľvek dostupnom prostredí, aby sa testovanie začalo včas.
Sú časy, keď sa test produktu (nazývaný tiež ako systémový test) a testovania UAT prekrývajú, a preto je potrebné pokračovať v paralelnom testovaní s viacerými prostrediami.
Existujú prípady, keď vývojový tím potrebuje ďalšie prostredie na ladenie problémov nahlásených testovacím tímom. Vývojový tím má tiež vyhradené prostredie pre úlohy testovania jednotiek.
Preto vo viacerých prostrediach musí byť v defekte uvedené konkrétne prostredie, v ktorom bol problém nájdený.
Scenár
Scenár je sada krokov vykonaných testerom, ktoré viedli k chybe. Tu sa od testera očakáva, že uvedie všetky kroky, ktoré vývojár môže vykonať na reprodukciu defektu. Často sú časy, keď je chyba hlásená testerom, ale vývojár nie je schopný replikovať to isté a preto je defekt odmietnutý. Môže k tomu dôjsť v dôsledku nesprávnych krokov / chýbajúcich krokov uvedených v popise. Jasné kroky pomáhajú každému porozumieť chybe a replikovať ju bez toho, aby záviseli od oslovenia testera, aby získal vstupy. Dobre zdokumentovaný scenár má ľahko čitateľné, ľahko zrozumiteľné a presné kroky, ktoré treba dodržať pri replikácii poruchy.
Testovacie dáta
Tester by mal spomenúť údaje použité v priebehu testovania, ktoré viedlo k problému. Táto informácia dáva vývojárovi šancu použiť podobné údaje na reprodukciu chyby a na nájdenie jej hlavnej príčiny.
Existujú niektoré scenáre, v ktorých tester nájde defekt pomocou konkrétnych údajov, ale ten istý problém nie je reprodukovateľný pomocou podobného druhu údajov. Môže k tomu dôjsť v dôsledku poškodenia údajov, preto zadanie údajov dáva šancu zistiť hlavnú príčinu chyby. Ak dôjde k poškodeniu údajov, vývojár nemusí zistiť úroveň kódu. Tento druh chyby možno previesť na dátovú chybu.
Očakávaný a skutočný výsledok
Toto je zvýraznenie poľa podrobného popisu, kde tester preukáže, že zistená chyba je skutočne chybou. Jednoznačné uvedenie očakávaného výsledku objasňuje všetkým zúčastneným stranám, aby túto chybu považovali za chybu. Predstavte si, že chyba je zaznamenaná so všetkými podrobnosťami, ale nešpecifikuje očakávaný výsledok scenára!
Tester zvyčajne zadáva iba očakávaný výsledok, ktorý môže byť v jednej alebo dvoch líniách, je však veľmi dôležité uviesť zdroj očakávaného výsledku. Zdroj tu odkaz na dokument, kde je uvedený očakávaný výsledok. Môže to byť dokument s požiadavkou alebo odkaz na storyboard.
Odkaz na súbory / údaje
Porucha niekedy zahrnuje vytvorenie súboru alebo vstupu ako súboru. V takýchto scenároch má tester poskytnúť informácie o súbore, ktorý bol použitý a ktorý spôsobil problém v aplikácii. Tieto súbory môžu byť pripojené pomocou nástroja na správu defektov alebo je možné poskytnúť odkaz na ne. Tieto referenčné miesta by mali byť prístupné všetkým zainteresovaným stranám.
Odkaz na snímku
Snímky hrajú veľmi dôležitú úlohu, ak im chcete ukázať presné chybové hlásenie o zlomení stránky, ako sa zobrazuje na obrazovke alebo ak chcete zobraziť podrobnosti navigácie na obrazovke. Snímka poskytuje rýchlu predstavu o výskyte chyby, obrazovke, na ktorej bola chyba nájdená, údajoch použitých na obrazovke atď. Každý nástroj na správu defektov má zabezpečenie na pripojenie snímok. Niekedy môže tester pripojiť aj tabuľky programu Excel alebo slovo dokumenty.
Boli to rôzne súčasti zaznamenávania chýb a osvedčené postupy pre každú z nich. Po návrate k životnému cyklu defektu, akonáhle je defekt priradený vývojárovi, analyzuje ho pomocou údajov poskytnutých v defektnej položke. Ak je podľa analýzy zaznamenaný problém skutočne chybou, vývojár chybu „otvorí“ a bude pracovať na jej oprave.
Odporúčané kurzy
- Webové služby v balíku Java Training Bundle
- Školenie o vývoji hier v C ++
- Kompletné školenie o etickom hackingu
- Výcvikové kurzy Vegas Pro 13
Nové - otvorené
Chyba v otvorenom stave ukazuje, že je vo vývojovej doske a vývojári pracujú na jej oprave. V prípade, že analýza zistí, že zaznamenaný problém nie je chybou, môže sa to stať, keď existuje očakávaná medzera v porozumení očakávaného správania systému. Ak analýza tvrdí, že chyba je neplatná, vývojár chybu odstráni. Terminológia je „Odmietnuté“ alebo „Návrat k testovaniu“.
Nový - návrat k testovaniu.
Ako by mal tester overiť, či bola chyba skutočne neplatnou?
Toto je scenár, v ktorom dokument s presnou požiadavkou pomôže každému v tíme dospieť k záveru, či bola zaznamenaná chyba neplatná alebo platná. Odkazovanie na dokumenty s požiadavkami pomáha testerovi aj vývojárovi dospieť k rovnakému záveru a skutočne to uľahčí proces diskusie.
Existujú scenáre, v ktorých sa spochybňuje správnosť dokumentov o návrhu a požiadavkách, zatiaľ čo v čase diskusií o chybách sa tieto dokumenty odkazujú, v takomto prípade sa návrat k Business Analyst považuje za najlepšiu možnosť objasnenia otázok.
Ako najlepšia prax by dokumenty týkajúce sa požiadaviek a dizajnu mali byť vždy aktuálne, aby sa na ne mohli odkazovať bez akýchkoľvek nejasností.
V stave „Otvorený“ vývojový tím pracuje na odstránení chyby. Po odstránení chyby sa stav zmení na „Pripravený na nasadenie“.
Otvorené - pripravené na nasadenie
Nasadenie je proces, v ktorom sa zmeny ukladajú na server, aby testovací tím mohol pracovať na pevnej verzii kódu. Každý projekt má zvyčajne samostatný tím nasadenia pre túto úlohu.
Na vysokej úrovni teda softvérový tím pozostáva hlavne z týchto 3 skupín -
- vývoj
- Poškodenie životného cyklu pri testovaní
- Nasadenie (alebo niekedy nazývané ako tím zostavenia)
Akonáhle je zostavenie nasadené a defekt je opäť k dispozícii na opakované testovanie, je priradený príslušnému testerovi pre opakované vykonanie úlohy.
Chyba priradená - testovací zvod.
Testovací vodič - individuálny tester.
Priradená chyba - individuálny tester.
Na niektorých pracoviskách je chyba najskôr priradená k testovaciemu vodičovi a on ju zase priradí jednotlivému testerovi, ale na niektorých miestach je chyba priradená priamo testerovi, ktorý by ju testoval alebo tomu, kto chybu odstránil.
Stav sa tu zmení z stavu Ready for Deployment - Ready SIT Testing.
Teraz je chyba v doske testera. Testovací tím overí chybu a existujú dve možnosti, buď oprava bude fungovať správne, alebo sa rovnaký problém objaví znova. V závislosti od výsledku sa chyba môže presunúť do nasledujúcich stavov -
Ready SIT Testing - Closed
Ready SIT Testing - Opätovné otvorenie
V obidvoch vyššie uvedených scenároch je tester povinný pridať komentáre vykonaného testovania. To zahŕňa uvedenie testovaných scenárov a použitých údajov. Ak sa chyba znovu otvorí, tester by mal poskytnúť presné vykonané kroky, ktoré opäť viedli k chybe.
Stav opätovného otvorenia je rovnaký ako stav „Nový“.
Po opätovnom otvorení chyby bude nasledovať rovnaký cyklus.
Poruchy životného cyklu
- Rozhodovanie o závažnosti defektu - to je jedna z bežných tém diskusie (často bojuje) medzi vývojármi testerov.
- Vada nie je reprodukovateľná v systéme vývojára.
- Chyba uvedená v scenári, ktorá nie je uvedená v požiadavkách a projektových dokumentoch.
- Defekt sa zistí, ale to isté nemožno vzniesť, pretože výskyt scenára na výrobnom prostredí nie je uskutočniteľný.
Ako by mal tester prekonať vyššie uvedené problémy?
- Závažnosť je priamo úmerná dopadu, ktorý defekt spôsobuje aplikácii, ak tester nemôže kvôli chybe pokračovať, je určite označený najvyššou závažnosťou.
- Ak existuje riešenie na pokračovanie v testovaní, malo by sa to označiť ako stredne závažné. Okrem zváženia dopadu ďalšieho testovania životného cyklu defektov sa tiež môže rozhodnúť o závažnosti vzhľadom na situáciu, keď celý modul zlyhá, v tomto prípade, aj keď je možné vykonať testovanie iného modulu, ale závažnosť súčasného modulu je vysoká. takže chyba by mala byť označená s najvyššou závažnosťou.
- Ak chyba nie je reprodukovateľná v systéme vývojára, existuje šanca, že vývojové a testovacie prostredie nie je synchronizované. Defekt reprodukovateľný v testovacom systéme sa vždy považuje za platnú chybu.
- Existujú situácie, keď je chyba zaznamenaná vzhľadom na celkový obchodný scenár, ale priamy scenár nie je uvedený v požiadavkách alebo v konštrukčnom dokumente. Vždy sa považuje za najlepší postup, keď sa berú do úvahy skutočné obchodné scenáre, a nie iba postupovať podľa testovacích krokov. Komunikácia s obchodnými analytikmi a inými zainteresovanými stranami v oblasti produktov zohráva dôležitú úlohu pri zaznamenávaní takýchto chýb.
- Existujú scenáre, keď tester zistí medzeru v obchodnej logike počas fázy testovania. Nájdenie takýchto medzier sa opäť považuje za veľké plus pre testera. Dizajnové medzery sa zvyčajne riešia vylepšeniami.
- Vylepšenie - Ak je potrebné zmeniť správanie počas testovacej fázy životného cyklu softvéru, vytvorí sa vylepšenie, ktoré je možné vykonať v aktuálnom alebo nasledujúcom vydaní vzhľadom na časové harmonogramy a šírku pásma vývojových a testovacích tímov.
- Existujú niektoré scenáre, ktoré by tester mohol testovať počas ad hoc testovania, čo by v skutočnosti mohli byť neplatné scenáre, berúc do úvahy možnosť ich výskytu vo výrobe.
Kto je najlepším priateľom testera?
Kam by mal tester ísť v prípade nejasností? Odpoveď závisí od typu dotazu, ak sa dotaz týka požiadaviek, je vhodné najprv diskutovať v tíme, aby sa správne pochopenie systému mohlo uskutočniť konzultáciou s vyššími členmi. Ďalším kontaktným miestom by mali byť obchodní analytici.
Ak sa dotaz týka procesu testovania, je vhodné osloviť testovacieho elektródy alebo manažéra testovania.
Ak sa dotaz týka porozumenia technickým aspektom aplikácie, člen vývojového tímu by mohol byť tou správnou osobou.
Pretože testovanie je proces, ktorý si vyžaduje celkové porozumenie systému, komunikácia pomáha testerovi získať rýchlu odpoveď na otázky, závisí to iba od kladenia správnych otázok správnym jednotlivcom. Vyhýbanie sa kladeniu otázok v správny čas môže viesť k chybe presakujúcej do výrobného prostredia.
Aká dôležitá je úloha testera v spoločnosti dnes?
Existujú projekty, v ktorých je testovací tím rovnako dôležitý ako vývojový tím av niektorých prípadoch je väčšia závislosť od testovacieho tímu ako od vývojového tímu. Posledný scenár je zriedkavý, ale na niektorých pracoviskách existuje. Stalo sa to v priebehu času a môže to byť na určité konkrétne časové obdobie, keď vývojový tím nemá veľa skúseností s testovacím tímom. Existujú ľudia, ktorí chápu celkový tok a funkčnosť lepšie ako väčšina ostatných členov tímu. Takýto jednotlivec by mohol byť súčasťou testovacieho / vývojového tímu. Toto je jeden z faktorov, ktorý určuje závislosť konkrétneho projektu od tímu / jednotlivca.
Aká je kariérna cesta pre testera?
Jednotlivec môže chvíľu trvať, aby pochopil celkový proces testovania, doménu a ďalšie úlohy, od ktorých sa očakáva, že budú pracovať v každodennom živote. Na základe tohto porozumenia je vhodné prijať rozhodnutie o preskúmaní ďalších oblastí, ktoré by tester mohol prijať. V procese sú vždy príležitosti na automatizáciu rôznych tokov. Vytvorenie malých utilít môže tímu tiež pomôcť. Ak je tester dobrý v programovaní, považuje sa to za veľké plus. To otvára príležitosti pre automatizačné úlohy. Testovanie výkonnosti je tiež jednou z kariérnych možností pre testerov. Ďalšou možnosťou je obchodný analytik. Dobrá znalosť domény s dobrými komunikačnými schopnosťami je požadovaná súprava zručností, aby boli obchodnými analytikmi. Testovanie otvára testerom mnoho príležitostí na prácu v rôznych doménach, nástrojoch, procesoch atď. Závisí to len od toho, či sa jednotlivec zdvihne a začne hlboko v jednej z hlavných oblastí testovania. Existuje mnoho certifikátov špecifických pre rôzne nástroje, ktoré sa špecializujú na jednu oblasť testovania. Certifikácia od štandardného dodávateľa je výhodou na podporu kariéry, ale samotný certifikát vám v dlhodobom horizonte nemôže pomôcť, ak sa nespája so správnymi pracovnými skúsenosťami.
Odporúčané články
Tu je niekoľko článkov, ktoré vám pomôžu získať viac podrobností o testovaní softvéru, stačí prejsť na odkaz.
- 6 najzaujímavejších otázok týkajúcich sa testovania softvéru
- Kariéra v testovaní softvéru
- Ako získať lepší kariérny rast v softvérovej testovacej práci