defect triage process
Kompletný sprievodca procesom Defect Triage a efektívne spôsoby riešenia schôdzky Defect Triage:
V dnešnom článku sa dozvieme o stretnutí Defect Triage a o tom, ako zvládnuť triediace stretnutie jednoduchšie a efektívnejšie.
Pred pokračovaním v tomto článku by som si prial, aby všetci vedeli, čo sa rozumie pod chybou, životným cyklom chyby a ako nastaviť prioritu a závažnosť pre každú chybu . A je potrebné porozumieť týmto základným pojmom súvisiacim s chybou alebo chybou.
Môžete tiež prejsť mojím starším článkom „ Porucha životného cyklu a Proces správy defektov „ rýchlo pochopiť tieto pojmy.
Čo sa dozviete:
- Prehľad
- Porada Triage Meeting
- Šablóna na odstránenie chyby
- Proces defektného sania
- Úlohy a zodpovednosti
- Záver
- Odporúčané čítanie
Prehľad
Slovo 'Triedenie' sa v zásade používa v lekárskej oblasti. V skutočnosti sa rozhodovalo o poradí, v akom majú byť pacienti liečení. Zvyčajne vo veľkých nemocniciach, kde existujú tisíce prístupov pacientov ku konzultáciám alebo ku skutočnej liečbe každý deň. Ale nie všetci pacienti sú prijatí alebo liečení okamžite.
Závažnosť ochorenia alebo úrazu sú hlavnými kritériami konzultácie a na základe toho sú všetci pacienti kategorizovaní podľa toho. Ak je zranenie alebo zdravie ktoréhokoľvek pacienta veľmi kritické, potom lekári zvyčajne považujú týchto pacientov za prioritu a v prípade potreby sú prijatí.
Normálne choroby alebo nekritické poranenia sa považujú za látky s nižšou prioritou a títo pacienti sa liečia neskôr.
Podobne sa pojem Triage zavádza do testovania softvéru na chyby aplikácie alebo projektu. Proces Defect Triage sa zvyčajne realizuje vo veľkých projektoch a v mnohých prípadoch sa ho netýka malých projektov. Existuje šanca identifikovať veľké množstvo chýb vo väčších projektoch ako v stredných alebo malých projektoch.
Aj vo väčších projektoch je frekvencia identifikácie chýb dosť vyššia.
Zoznámte sa s obrázkom nižšie, ktorý zobrazuje výsledky schôdzky Triedenie defektov a poskytuje odpovede na konkrétne otázky, ako napríklad:
Porada Triage Meeting
Hlavným cieľom triediacej schôdzky je sledovanie všetkých nedostatkov a včasné zabezpečenie správneho riešenia.
Počas fázy vykonávania testu začnú testeri hlásiť chyby v nástroji Správa defektov, ako je napr HP ALM , QC atď. Potom Porada Triage Meeting sa koná konferencia, na ktorej sa vyžaduje prítomnosť vývojárov a testerov, pretože títo ľudia budú diskutovať o všetkých chybách a podniknú potrebné ďalšie kroky.
Povinne sa vyžaduje hlavne prítomnosť nižšie uvedených účastníkov:
- Projektový manažér
- Testovacie vedenie
- Vedúci vývoja alebo vývojár
- Tester
- Manažér testov
- Obchodný analytik
- Manažér životného prostredia
Aj keď som uviedol vyčerpávajúci zoznam všetkých účastníkov stretnutia, nie je potrebné zapojiť do denného stretnutia všetkých ako Business Analyst, Environment Manager, Test Manager atď. Kedykoľvek je to potrebné, pozve ich vedúci testu alebo vedúci projektu a môžu sa podeliť o svoju cennú spätnú väzbu a názor týkajúci sa konkrétnej chyby.
A celý tím je známy ako Triage Team . Teraz vysvetlím presný proces triediacej schôdzky a ako je táto schôdza nastavená.
Zvážte jeden hypotetický príklad :Máme jeden projekt súvisiaci s bankovou aplikáciou, veľkosť je veľmi veľká a frekvencia identifikácie a hlásenia chyby je vysoká. Z tohto dôvodu sa testovací vedúci rozhodne zorganizovať Stretnutie s odstránením chyby s požadovanými účastníkmi.
unixové otázky a odpovede pre skúsených
Pre nastavenie stretnutia pošle testovací vedúci e-mailom pozvánku na stretnutie a nastaví konkrétne načasovanie stretnutia Triage. Nižšie uvedený hypotetický obrázok zobrazuje pozvánku na stretnutie zaslanú testovacím vedúcim prostredníctvom programu Outlook všetkým účastníkom.
Na nasledujúcom obrázku je všetko imaginárne ako - mená účastníkov, konferenčná miestnosť, podrobnosti konferenčného hovoru, dátum, čas atď.
(Poznámka:Kliknutím na ľubovoľný obrázok zobrazíte zväčšené zobrazenie)
Každý deň pred začiatkom hodnotiacej schôdze testovací vedúci pošle všetkým účastníkom zoznam všetkých „otvorených“ nedostatkov vo formáte tabuľky, aby mohli prekonať všetky nedostatky pred stretnutím a pochopiť, o čo presne ide. a aký druh opravy je pre to potrebný.
Pred začiatkom každého triediaceho stretnutia sa uistite, či každá porucha:
- Má dostatok informácií na pochopenie chyby pre všetkých účastníkov stretnutia.
- Bol uvedený v správnom projekte a kategórii.
- Spomenul prioritu a závažnosť chýb.
- Všetky podrobné informácie poskytnuté v prípade poruchy, aby ju všetci účastníci správne pochopili.
Odporúčané čítanie => Kompletný sprievodca procesom riadenia defektov
Šablóna na odstránenie chyby
Pred začiatkom každého stretnutia týkajúceho sa defektov testovací vodič zdieľa správu o defekte všetkým účastníkom v konkrétnom formáte a správa vytiahnutá z nástroja na správu defektov, ako sú HP ALM, HP QC atď. Zobrazujem jeden vzorový formát v pod obrázkom, ktorý na vysokej úrovni poskytne predstavu o tom, ktoré polia sú uvedené v šablóne hlásenia o chybe.
Polia zahrnuté v hlásení o chybe sú zvyčajne:
- ID chyby
- Popis
- Priorita
- Závažnosť
- Zistený dátum
- Zistené používateľom
- Postavenie
Zoznam nie je vyčerpávajúci, ale podľa potreby projektu je možné zahrnúť ďalšie polia do šablóny správy o chybe.
Formát tabuľky sa zvyčajne používa ako šablóna na hlásenie chýb, a preto som vo formáte tabuľky uviedol hypotetické podrobnosti o chybe. Upozorňujeme, že všetky informácie uvedené vo vyššie uvedenom hlásení o chybe sú iba imaginárne a nevzťahujú sa na žiadny projekt alebo skutočnú aplikáciu.
Proces defektného sania
Bežne počúvanou a skúsenou situáciou v testovacích tímoch je obmedzená dostupnosť zdrojov. Triedenie chýb je proces, ktorý sa v dôsledku tohto javu snaží dosiahnuť určité vyváženie. Takže ak existuje veľa chýb a je obmedzených vývojárov / testerov, ktorí ich majú opraviť / overiť, triedenie chýb pomáha dosiahnuť čo najviac chýb odstránením vyváženia technického personálu na základe parametrov chýb, ako sú priorita a závažnosť.
Relácie triedenia chýb sa zvyčajne zúčastňujú produktový manažér, vedúci vývoja, testovací vedúci a niekedy obchodní analytici. V niektorých prípadoch môžu byť vyzvaní aj ďalší členovia, aby vyjadrili svoje názory a názory na určité nedostatky. Spoločne sa nazývajú triediaci tím.
Väčšina systémov používa prioritu ako hlavné kritérium na posúdenie chyby, avšak dobrý proces triedenia zohľadňuje aj závažnosť.
Pozrime sa podrobnejšie na proces triedenia pomocou dvoch príkladov, o ktorých sme hovorili v predchádzajúcej časti. V obidvoch vyššie uvedených príkladoch by to bola skutočne prvá chyba, ktorej by bola daná veľmi vysoká priorita. Napriek tomu, že ide iba o kozmetickú chybu, dopad neopravenia by bol obrovský.
Druhý je na druhej strane nepochybne funkčným nedostatkom, jeho výskyt je však iba za určitých podmienok, ktoré sú zriedka praktickými scenármi zákazníka. Jeho oprava môže vyžadovať viac času a ľudí, čo by sa dalo lepšie využiť pri ďalších chybách. Preto by sa to považovalo za nižšiu prioritu ako u prvého a možno odloženého kandidáta na ďalšie vydanie.
Triediaci proces teda spočíva v tom, že triediaci tím si spolu sadne a skúma všetky chyby vrátane odmietnutých. Vypracujú počiatočné vyhodnotenie chýb na základe ich obsahu, príslušnej priority a nastavenia závažnosti; s každou osobou v triediacom tíme predstaví svoj pohľad na to, ako uprednostniť chyby.
Produktový manažér potom nastaví prioritu na základe všetkých vstupov a priradí chybu k správnemu uvoľneniu, tj. v aktuálnom vydaní alebo v akomkoľvek budúcom vydaní. Poruchu tiež presmeruje na správneho vlastníka / tím pre ďalšiu akciu. Odmietnuté chyby sa tiež podrobia podobnej analýze. Na základe dôvodu odmietnutia sa určuje futuristická akcia, či je potrebné ju odložiť alebo zrušiť.
Na triediacom stretnutí by sa mala prediskutovať každá chyba, vrátane chýb, ktoré sú kategorizované ako chyby s nižšou prioritou. Prieskumný tím hodnotí všetky chyby a pri každej chybe prijíma potrebné opatrenia. Ak defekt nemá dostatok informácií, vývojár ich spätne pridelí testerom a požiada o potrebné informácie.
Triediace stretnutie sa môže konať v zasadacej miestnosti, ak sú všetci účastníci na rovnakom mieste. Ale v mnohých organizáciách sa práca vykonáva z iného miesta a všetky tímy sa nachádzajú na rôznych miestach, takže sa schôdza koná aj pomocou telekonferencie alebo obchodného Skype.
[ obrázok zdroj ]
Postup krok za krokom porady s triedením porúch:
- Testovací vodič zaháji stretnutie správou o chybe, ktorá bola odoslaná skôr v daný deň.
- Diskusia sa začína činnosťami čakajúcimi na predchádzajúcom stretnutí triedenia. Spočiatku sa hovorí o potrebných aktualizáciách alebo opatreniach, ktoré sa podnikli pri akejkoľvek chybe.
- Ak sa v správe o chybách vyskytnú nové chyby, tieto chyby sa skontrolujú a vyhodnotia. Tiež overuje, či sú priorita a závažnosť pridelené správne, ak nie, potom sa tieto na stretnutí opravia.
- Všetky chyby sú prediskutované na stretnutí a vývojový tím diskutuje aj o zložitosti ich odstránenia. Riziko spojené s chybou rozoberá aj triediaci tím.
- Tím spoločnosti Triage dospeje k záveru, ktorá chyba by si mala vyžadovať okamžitú pozornosť a opravu a ktorá chyba si musí nejaký čas počkať, a ak je to potrebné, tieto chyby je možné odložiť na ďalšie verzie.
- Všetky chyby sú pridelené príslušnému tímu v QC alebo ALM súčasne počas stretnutia. Príslušné poznámky sú tiež pridané do QC / ALM.
- Všetky dôležité aktualizácie a úlohy sú zaznamenané a testovací vodič zavolá na koniec stretnutia.
- Po dokončení triediacej schôdzky zašle testovací vedúci všetkým účastníkom zápisnicu zo schôdzky.
Úlohy a zodpovednosti
Úlohy a zodpovednosti založené na jednotlivých kategóriách sú vysvetlené nižšie:
Testovacie vedenie
- Testovací vedúci naplánuje schôdzku na triedenie defektov a pošle formálnu pozvánku na schôdzku požadovanému tímu.
- Odošle správu o chybe pred každým triediacim stretnutím.
- Odštartuje stretnutie s nevybavenými akčnými položkami z predchádzajúcej triage stretnutia.
- Diskutujte o každej chybe a dopade na plán, ak sú kvôli funkcii blokované nejaké funkcie.
- Pomáha pri prideľovaní priority a závažnosti každej chyby, ak nebola správne priradená skôr.
- Aktualizujte QC / ALM príslušnými komentármi.
- Poznačte si všetky aktualizácie, akcie, riziká spojené s chybou atď.
- Odošle všetkým účastníkom zápisnicu.
Vedúci vývoja / vývojár
- Zdieľajte aktualizácie o úlohách čakajúcich na poslednú triediacu schôdzku.
- Diskutujte o všetkých chybách z technického hľadiska.
- Podľa zložitosti chyby a funkčnosti určte, koľko času to bude vyžadovať na opravu.
- Diskutujte o zložitosti chyby a riziku spojenom s chybou, ak nejaké existuje.
- Po potvrdení všetkých dostupných podrobných informácií vývojový pracovník pridelí chybu príslušnému vývojárovi.
- Aktualizuje chybu na očakávaný dátum riešenia.
- Pomáha pri identifikácii hlavnej príčiny poruchy.
Projektový manažér
- Zaistite, aby boli na stretnutí k dispozícii všetci zástupcovia z každej oblasti.
- V prípade potreby pozve projektový manažér na schôdzku obchodného analytika, aby vyjadril svoj názor na konkrétnu vadu.
- Ak sa chyby nepohybujú alebo existuje nejaký väčší blokátor, postupuje sa s procesom eskalácie.
- Ak je to potrebné, koná ako sprostredkovateľ v prípade akýchkoľvek sporov alebo konfliktov medzi tímami a prijíma potrebné rozhodnutia.
- Odebratie potvrdenia od vývojového tímu o budúcom dátume vydania.
- Uvedomte si aktualizovaný harmonogram a dátum uvedenia projektu pre všetky tímy.
Občas je tiež dobré zapojiť ďalších členov tímu do triediaceho hovoru, aby tiež pochopili a prispeli k stretnutiu a v prípade potreby mohli poskytnúť aj svoju spätnú väzbu.
Záver
Každá zaznamenaná chyba by mala byť prediskutovaná na triediacej schôdzi.
Aj keď je chyba odmietnutá, testovací tím by mal poznať dôvod odmietnutia. Pokiaľ nie je niektorý z defektov reprodukovateľný, môže vývojár počas triaingového stretnutia požiadať testerov o podrobnosti v reálnom čase a pokúsiť sa tento defekt reprodukovať.
Porucha Triage je dôležitá, pretože každý bude vedieť, kedy bude chyba opravená a bude k dispozícii na opätovné testovanie. Ak niektorá z chýb nie je kritická a na odstránenie chyby si vyžaduje vývojové tímové úsilie a rozhodnutie prijme projektový manažér.
Projektový manažér rozhodne o priorite takejto chyby a v prípade potreby ju možno posunúť na ďalšie vydanie.
Dúfam, že by ste mali jasnú predstavu o defektnom prepravu, procese defektnej prepravy a spôsoboch, ako efektívne zvládnuť stretnutia s defektnou prepravu!
Odporúčané čítanie
- Proces správy defektov: Ako efektívne riadiť defekty
- Čo je to technika testovania na základe chýb?
- Metódy a techniky prevencie defektov
- Čo je životný cyklus chyby / chyby v testovaní softvéru? Výukový program pre poruchu životného cyklu
- Výukový program Bugzilla: Výukový program pre nástroj na správu chýb
- Výukový program pre centrum kvality Micro Focus (6. deň) - Správa chýb
- Defektné triaanie v skrumáži: Ako je to organizované v nastavení skrumáže
- 3 najhoršie zvyky pri hlásení defektov a ako ich zlomiť