Menu

Vzorová šablóna pre správu o prevzatí s príkladmi

sample template acceptance test report with examples

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Prehľad správy o prevzatí (časť III):

Predchádzajúci návod | NEXT Tutorial

V našom predchádzajúcom návode na tému „ Dokumentácia o testovaní prijatia so scenármi v reálnom čase ”Diskutovali sme o pláne Acceptance Test.

V tomto tutoriáli sa podrobne pozrieme na vykazovanie stavu Acceptance Test Status, Acceptance Test Summary a Sign-Off.

V tomto výučbe sú zahrnuté niektoré všeobecné šablóny, ktoré vám pomôžu lepšie porozumieť. Budeme sa tiež pohybovať nad konceptom Acceptance Testing v agilnom a Acceptance Test Driven Development.

Stručne povedané, tento tutoriál vám vysvetlí správu o stave a súhrnnú správu o prijímacom teste spolu s niektorými všeobecnými šablónami pre vaše jasné pochopenie a tiež ľahko a zrozumiteľne opráši koncepciu prijímania pri agilnom a testom riadenom vývoji.

Šablóna skúšky prijatia

Čo sa dozviete:

Správa o stave kolaudácie

Správa o preberacom teste by mala vždy sumarizovať preberacie testy, ktoré sa vykonávajú, spolu s ich výsledkami. Malo by byť určené všetkým identifikovaným zainteresovaným stranám, ktoré sú súčasťou fázy testovania prijatia. Len čo sa začalo s vykonaním testov prijatia, pokrok by sa mal hlásiť zo dňa na deň.

Všeobecná šablóna pre správu o stave skúšky prijatia:

Dátum :Dátum správy o stave kolaudácie

Dnešné podrobnosti vykonania testov prijatia:

  • Počet úspešne absolvovaných testov
  • Počet zlyhaných testov
  • Počet prebiehajúcich testov

Podrobnosti o vykonaní testov prijatia do dátumu:

  • Celkový počet testov
  • Počet úspešne absolvovaných testov
  • Počet zlyhaných testov
  • Počet prebiehajúcich testov
  • Počet nespracovaných testov

Podrobnosti o chybe:

c ++ kód triedenia vloženia
  • Počet zaznamenaných chýb
  • Každá chyba by mala obsahovať nasledujúce podrobnosti:
    • ID, zhrnutie, komponent, závažnosť
  • Celkový počet doteraz zaznamenaných chýb (vo fáze testovania prijatia).

Táto správa sa musí každý deň prehodnocovať, aby sa zabezpečilo, že vykonávanie je na dobrej ceste a že sa nevychyľujú k plánovaným harmonogramom.

Súhrnná správa o kolaudácii

Toto je správa, ktorá sumarizuje stav celej fázy Acceptance Testing. Patria sem podrobnosti, ako sú vykonané testovacie činnosti, odkazy na splnené kritériá, špecifikácie požiadaviek, obchodné pravidlá, výsledky vykonávania, plánované plány, odchýlky atď.

Všeobecná šablóna pre súhrnnú správu o kolaudácii:

Zhrnutie

Odchýlky

Odchýlky

Výsledky

Správy

Vyhodnotenie

Odporúčanie

závažnosť porúch a Pass rate ovplyvňuje odporúčanie pre produkt, ktorý má byť uvedený na trh

Úsilie

Úsilie

Správa o odhlásení

Keď produkt prejde testom prijatia, bude odporúčané spustiť ho naživo. Pred spustením do produkcie musí byť formálne odhlásený.

Všeobecná šablóna pre správu o odhlásení:

Názov produktu, verzia vydania, číslo zostavy

Posledná správa

Skontrolované dňa

Hodnotené

Skontrolujte komentáre

Dátum odhlásenia

Odhlásiť sa

Prihlasovacie komentáre

Všeobecne platí, že ktorékoľvek z vyššie uvedených správ by mali byť skontrolované hlavnými zúčastnenými stranami, pokiaľ ide o ich vzor, ​​a musí byť dohodnuté, čo musí ísť ako informácia do.

Pred zdieľaním so správou so zainteresovanými stranami by mali byť skontrolované všetky podrobnosti, ktoré sú do nej vyplnené. Akékoľvek nezrovnalosti v správe budú mať výrazný dopad na obchodné rozhodnutie a môžu mať za následok zlyhanie produktu na trhu.

Hlásenie by preto vždy mali spracúvať špecialisti alebo starší členovia tímu.

Akceptačné testovanie v agile

V Agilný „Kritériá prijatia každého príbehu používateľa sú zamerané na testy prijatia, t. J. Testy prijatia sú odvodené z kritérií prijatia príbehu používateľa. Každé kritérium prijatia môže mať jeden alebo viac testov prijatia na pokrytie scenára.

Akceptačné testy sú zvyčajne vypracovávané QA, ktorý je odborníkom v danej oblasti. Akceptačné testovanie v systéme Agile sa začína oveľa skôr v porovnaní s ostatnými prístupmi, zvyčajne v rámci samotných šprintov.

Vykonáva sa veľmi často, pretože v každom šprinte budú prichádzať nové príbehy používateľov a tiež vylepšenia / pokračovania predchádzajúcich príbehov.

Akceptačné testy sa v systéme Agile vykonávajú v dvoch rôznych fázach:

  • Keď je funkcia vytvorená a v počiatočnej fáze - základná.
  • Keď je funkcia integrovaná a stabilizovaná s ostatnými funkciami produktu.

Každý príbeh používateľa musí prejsť testom prijatia a mal by byť schválený. Akékoľvek zlyhania v Akceptačnom teste by sa mali považovať za vysokú prioritu a mali by sa okamžite opraviť. To bude mať za následok vykonanie akceptačného testu.

Body príbehu sú každému príbehu používateľa pridelené na základe úspešnosti výsledkov Akceptačného testu pre každé z akceptačných kritérií. Acceptance Testing tiež definuje dokončenie na úrovni Príbehu používateľa s tým, že sú splnené kritériá prijatia pre príbeh.

Kto prijíma testy v agile?

Produktoví manažéri, odbornosť predmetu (môžu to byť testeri zákazníkov A / ALEBO Beta testéri) zvyčajne vykonávajú testy prijatia v agilnom prostredí. QA niekedy tiež zahŕňa túto aktivitu spolu so svojimi pravidelnými regresnými úlohami.

Výhody agilného testovania

Prijímacie testy v agile majú niekoľko výhod.

Výhody sú:

  • Užšia spolupráca medzi produktovým manažérom a tímom.
  • Vytvára dôveru na úrovni Príbehu používateľa.
  • Pomôže odvodiť viac scenárov, ktoré pokryjú každé kritérium prijatia.
  • Zvýšená pravdepodobnosť improvizácie riešení produktu prostredníctvom kritérií prijatia v Príbehoch používateľov.

Nevýhody

Aj keď existuje niekoľko výhod, existujú aj určité nedostatky.

Nevýhody zahŕňajú:

  • Nie všetky príbehy je možné zohľadniť pri teste prijatia. Zahrnuté budú iba funkčné príbehy - príbehové pokrytie sa môže znížiť.
  • Nie všetky kritériá prijatia môžu byť zohľadnené pri testovaní prijatia. Zahrnuté majú byť iba funkčné kritériá - pokrytie kritérií prijatia v rámci príbehu používateľa sa môže znížiť.
  • Pretože sú do projektu zapojené zainteresované strany z rôznych prostredí a keďže sa testovanie prijatia príbehom vykonáva priamo, je pre každého dosť ťažké byť na jednej stránke (v zásade pochopiť úroveň jednotlivých príbehov používateľov).
  • Pretože trvanie vydania je v porovnaní s inými prístupmi kratšie, je dosť ťažké vyhovieť testovaniu prijatia v rámci sprintov.

Vývoj riadený testom prijatia (ATDD)

Toto je jeden z postupov agilného vývoja, kde celý tím spoločne diskutuje o každom z kritérií prijatia užívateľského príbehu a okolo nich vytvára silné testy prijatia.

Je to tak preto, lebo rôzne pohľady od každého člena tímu poskytnú nový spôsob uvažovania pre každé z kritérií prijatia a prídu s veľkým počtom prijímacích testov pokrývajúcich viac scenárov. Niekedy ATDD sa tiež nazýva Story Test Driven Development (STDD).

V skutočnosti sa ATDD deje pred začiatkom vývoja. Takže vývojári v tomto prístupe budú vedieť, čo sa v skutočnosti očakáva a ako to dosiahnuť. Celý tím bude zdieľať spoločné chápanie funkcie a toho, čo sa buduje.

Toto popisuje, ako sa produkt vyrába, a na druhej strane poskytne reálnu predstavu o tom, ako bude produkt v skutočnosti fungovať skôr, ako bude odovzdaný na testovanie. Preto sa nazýva „ Vývoj riadený kolaudáciou “.

Záver

Akceptačné testovanie v ktoromkoľvek z jeho prístupov má spoločný cieľ budovať dôveru a spokojnosť zákazníkov s produktom, ktorý je vyvinutý pred uvedením do života. To sa dosiahne iba vtedy, ak na produkte nie sú žiadne / menej nedostatkov s nízkou závažnosťou, ktoré nebránia žiadnej z funkcií.

Stručne:

  • Akceptačné testy sú splnené.
  • Poruchy sú na prijateľnej úrovni.
  • Dosiahnuté pokrytie prietokom / scenárom.
  • Produkt a jeho riešenia sú akceptované.
  • Zákazník má vo výrobku dostatočnú istotu.
  • Všetky dokumenty k produktu sú aktualizované tak, aby zodpovedali najnovším funkciám.
  • Výsledok pre tímové úsilie.
  • Je dobré ísť vpred so spustením výroby.

Predchádzajúci návod | NEXT Tutorial

Dúfam, že by ste získali obrovské vedomosti z týchto návodov na testovanie prijatia. Neváhajte a podeľte sa o svoje myšlienky a položte svoje otázky v sekcii komentárov nižšie.

Odporúčané čítanie

^